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 20:38:25 GMT
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" <agrieve@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 <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
>>> >>>> >>
>>> >>>>
>>> >>>>
>>> >
>>>
>>
>>


Mime
View raw message