For patch releases, we haven't been making new JIRA versions, so you wouldn't be able to search for "Fix Version". It's also hard to know when you commit a change which version it will end up in (other than v-next). So probably git logs are the way to go for changelogs.
On Wed, Jul 31, 2013 at 4:38 PM, Filip Maj <f...@adobe.com> wrote: > 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" <agri...@chromium.org> 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 <agri...@chromium.org> > >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 <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 > >>> >>>> >> > >>> >>>> > >>> >>>> > >>> > > >>> > >> > >> > >
