cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Publishing to npm
Date Wed, 31 Jul 2013 19:43:43 GMT
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