cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Publishing to npm
Date Wed, 31 Jul 2013 19:53:12 GMT
That distinction is important: platforms continue monthly release
cadence. CLI tools are continuous delivery.


On Wed, Jul 31, 2013 at 12:43 PM, Filip Maj <fil@adobe.com> wrote:
> Agree with both of you: we should be tagging the tooling. Currently we
> follow the standard monthly release process that we apply to platforms. WE
> should probably change that.
>
> +1 to documenting release process. I will take time to do so for cli +
> plugman
>
> Email is the way to go. LEt's not mire ourselves with JIRA issues that
> committers may or may not receive notifications for. To Anis' point, my
> approach has been to notify interested parties on a particular feature/bug
> fix on a) the specific JIRA issues and b) the list if it is a sweeping
> change or a big feature. Sounds like we want to continue with this.
>
> So what shakes out here is: we need to figure out what the release process
> is for things that are on a different (more continuous?) release schedule
> compared to the platform implementations.
>
> On 7/31/13 11:54 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>
>>I think that is what we have been doing so far. We have been sending
>>an email out and waiting around 24 hours to give everyone a chance to
>>chime in.
>>
>>As far as process, this is how I have been doing it:
>>- Implement a feature/patch
>>- Write/run tests.
>>- Push to master.
>>- If it's a patch that fixes an issue then bump the version push it to
>>npm. Otherwise wait for next patch to do that.
>>
>>Missing: I think that every time we bump a version we should also tag
>>that version.
>>
>>-a
>>
>>On Wed, Jul 31, 2013 at 11:42 AM, Andrew Grieve <agrieve@chromium.org>
>>wrote:
>>> Right - yes, my goal is not to slow things down. Rather - if you go on
>>> vacation, I'd like the releases to keep coming and not stop with there
>>> being no instructions on how to do them (or worse - me pushing to npm
>>> incorrectly and breaking the world). E.g. are you pushing master? or are
>>> you working off of a 3.0.x release branch that's just for bugfix
>>> cherry-picks.
>>>
>>> I would like to increase visibility of releases though. I know you often
>>> email out when you update npm, but it's a lot of work to know what
>>>you've
>>> released. E.g. I know Anis is working on the registry, and in my eyes
>>> that's not a patch version type release. But has it gone out to npm
>>> already? Bug fixes are fine for patch releases, but new features are
>>>not.
>>>
>>> I actually dislike using JIRA for releases quite a bit. Maybe an email
>>> would suffice? I do think it would be worth emailing before releasing
>>> though. Even if it delays things 24 hours (I agree 72 hours seems
>>> excessive).
>>>
>>> The voting is not very useful for this project I don't think, but a
>>>second
>>> set of eyes goes a long way for sanity-checking what goes live. Maybe
>>>the
>>> npm process could involve getting agreement / sign-off from 2 devs?
>>>
>>>
>>>
>>> On Wed, Jul 31, 2013 at 2:29 PM, Filip Maj <fil@adobe.com> wrote:
>>>
>>>> I think Anis meant patch releases (we already create jira issues for
>>>>minor
>>>> releases, which come every month)
>>>>
>>>> On 7/31/13 11:26 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>>>
>>>> >I agree with Fil. I am ok with tagging every npm release but I don't
>>>> >think creating a Jira issue for minor point releases will be really
>>>> >beneficial.
>>>> >
>>>> >On Wed, Jul 31, 2013 at 11:07 AM, Filip Maj <fil@adobe.com> wrote:
>>>> >> I'd like to avoid a voting / consensus process _for EVERY RELEASE_
>>>>if
>>>> >> possible.
>>>> >>
>>>> >> We are including the tools in our monthly releases, and that I
>>>>think is
>>>> >> good enough in terms of following Apache process. This way there's
>>>>lazy
>>>> >> consensus per minor release.
>>>> >>
>>>> >> Being able to publish revisions to npm and fix bugs that way has
>>>>been a
>>>> >> positive experience for devs as well as users. Don't know why we
>>>>would
>>>> >> want to change that. Quick patch releases have been great for
>>>>building
>>>> >> confidence in our tools within our community.
>>>> >>
>>>> >> Filing a JIRA issue for every patch release is super overkill and
>>>>doing
>>>> >> lazy consensus for that seems even worse. We've had 5 patch
>>>>releases so
>>>> >> far since 3.0.0. Lazy consensus requires 72 hours of email
>>>>fermentation.
>>>> >> So that would mean we can release a max of 10 releases per month?
>>>> >>Doesn't
>>>> >> make sense to me.
>>>> >>
>>>> >> Tagging every npm release makes a lot of sense for all of our tools
>>>>/
>>>> >> plugins, but to be noted that we release tools/plugins differently
>>>>than
>>>> >> platforms, so figuring out the differences there would be a good
>>>>idea.
>>>> >>
>>>> >> On 7/31/13 10:54 AM, "Andrew Grieve" <agrieve@chromium.org>
wrote:
>>>> >>
>>>> >>>We're telling people to install plugman & cordova via npm,
but we're
>>>> >>>publishing updates to npm on a regular basis without any sort
of
>>>>release
>>>> >>>process. True?
>>>> >>>
>>>> >>>Or maybe npm has a way to publish dev versions that people won't
>>>>pick up
>>>> >>>by
>>>> >>>default?
>>>> >>>
>>>> >>>Either way, I'll start the ball rolling here:
>>>> >>>
>>>> >>>For a of any of our pieces (npm, plugins, platforms), I think
it's a
>>>> >>>must
>>>> >>>to have a wiki page documenting the release process. We have
this
>>>>for
>>>> >>>platforms (although it needs updating now that we're 3.0), but
we
>>>>need
>>>> >>>this
>>>> >>>for plugins & npm modules as well now.
>>>> >>>
>>>> >>>A release process should :
>>>> >>>1 - include testing procedures to follow when releasing
>>>> >>>2 - be detailed enough that anyone can perform the release
>>>> >>>3 - include a JIRA release issue to track the occurrence of the
>>>>release.
>>>> >>>4 - include creating a git tag for the release
>>>> >>>
>>>> >>>Anything else?
>>>> >>>
>>>> >>>
>>>> >>>All releases should also have a vote (even if it's recorded through
>>>>a
>>>> >>>JIRA
>>>> >>>issue). This is stated in the apache rules, but also serves the
>>>>purpose
>>>> >>>of
>>>> >>>making a release a team release instead of an individual release).
>>>>I'd
>>>> >>>like
>>>> >>>to see a release vote happen as an email that includes:
>>>> >>>1 - Main motivation for the release (even if it's just "time
has
>>>> >>>passed")
>>>> >>>2 - The changelog since the previous release.
>>>> >>>
>>>> >>>Make sense?
>>>> >>>
>>>> >>>Andrew
>>>> >>
>>>>
>>>>
>

Mime
View raw message