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