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 >
