Re: Publishing to npm

[Andrew Grieve <ag...@chromium.org>]

For patch releases, we haven't been making new JIRA versions, so you
wouldn't be able to search for "Fix Version". It's also hard to know when
you commit a change which version it will end up in (other than v-next). So
probably git logs are the way to go for changelogs.


On Wed, Jul 31, 2013 at 4:38 PM, Filip Maj <fi...@adobe.com> wrote:

> Committers as a whole on this project have been doing a pretty good job of
> tagging commits with relevant JIRA issues. Mayhaps we should try the JIRA
> generated change log thing as a first step to publishing patch release
> changes?
>
> On 7/31/13 1:35 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> >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 <ag...@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 <fi...@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" <an...@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
> >>><ag...@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 <fi...@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" <an...@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 <fi...@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" <ag...@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
> >>> >>>> >>
> >>> >>>>
> >>> >>>>
> >>> >
> >>>
> >>
> >>
>
>