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.ka...@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 <f...@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" <agri...@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 >>
