Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.220.48 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CABiQX1WUvfz3sLOoiBLxy3fgKVR4LXRMyuCodOiqsu_qzy+yKA@mail.gmail.com>
References: 
 <CANpVHHw7isM=Kq=Liqp+85QFgYbFNXiC-9645oh07qyFSUuHhQ@mail.gmail.com>
 <CE1EB670.23686%fil@adobe.com>
 <CADVgkyPs_+mfNBxMqVx8Nbo7XHfGwsykJ1dRNeO3iCO_WW1ffw@mail.gmail.com>
 <CABiQX1WUvfz3sLOoiBLxy3fgKVR4LXRMyuCodOiqsu_qzy+yKA@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Wed, 31 Jul 2013 16:35:53 -0400
Message-ID: 
 <CABiQX1Wn1L1w=PPqxsuznotPC8cZ-bUZQy5knsZ=5vZmQ_xgAw@mail.gmail.com>
Subject: Re: Publishing to npm
To: Andrew Grieve <agrieve@chromium.org>
Cc: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a1133780c33caeb04e2d4adc7

--001a1133780c33caeb04e2d4adc7
Content-Type: text/plain; charset=ISO-8859-1

One other thing I thought of - I think most releases (even patch ones) are
deserving of blog posts. I'll put it on my list tomorrow to create a wiki
page on the process for writing a blog post.


On Wed, Jul 31, 2013 at 4:19 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Great! Sounds like we all agree to agree :)
>
> Fil - Sounds good for you to do the initial Release Process write-up, and
> then we can ask questions / tweak if necessary afterwards.
>
>
>
> On Wed, Jul 31, 2013 at 3:53 PM, Brian LeRoux <b@brian.io> wrote:
>
>> 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
>> >>>> >>
>> >>>>
>> >>>>
>> >
>>
>
>

--001a1133780c33caeb04e2d4adc7--