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" <[email protected]> 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 <[email protected]> >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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >>><[email protected]> >>> >>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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >>>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" <[email protected]> >>> 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 >>> >>>> >> >>> >>>> >>> >>>> >>> > >>> >> >>
