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