Hello Everybody, Had some great conversations and feedback this week about the release process for Hawkular Metrics. A few ideas emerged and this email is a summary of the process Hawkular Metrics will implement starting next release (expected as soon as next week). Release Process: 1) Use semver as the versioning standard (http://semver.org/)

2) A scheduled release: a) is a planned release, with a set of significant changes b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) c) gets a dedicated branch from master d) gets tagged on the branch e) gets full release notes, JIRA, email communication, blog f) bits are published to JBoss Nexus and Github

3) A patch release a) needed to address urgent bugs or regression between scheduled releases b) is an increment in the PATCH version (eg. 0.4.2) c) no dedicated branch, patches are applied to the branch of a 'scheduled release' d) gets tagged on the working branch e) no release notes, blog posts, or similar communication; the only official communication will be a list of JIRAs fixed f) bits published to JBoss Nexus and Github g) all the code fixes will be applied retroactively to master

Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The 'patch releases' will be created on a need basis and only if there are JIRAs reported against the 'scheduled release' or 'patch release' that need to be addressed before the next 'scheduled release'. One goal with the patch releases is to avoid publish a huge number of them in a short amount of time (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; they will continue to get published from the code in the master branch. It would be great if all the projects converge on a similar process. I recognize that due to different maturity levels that might not be practical now for everybody, but it would be huge win for the entire Hawkular to make even small steps in the same direction. Thank you, Stefan Negrea Software Engineer _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

From: "Peter Palaga" <ppalaga(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Monday, June 15, 2015 3:19:24 AM Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components Hi Stefan, thanks for informing us how you will be doing things. It would be nice to hear more about your motivations for these particular decisions - see my "why"s inline. On 15/06/15 08:46, Gary Brown wrote: > Hi Stefan > > ----- Original Message ----- >> Hello Everybody, >> >> Had some great conversations and feedback this week about the release >> process >> for Hawkular Metrics. A few ideas emerged and this email is a summary of >> the >> process Hawkular Metrics will implement starting next release (expected as >> soon as next week). >> >> Release Process: >> 1) Use semver as the versioning standard (http://semver.org/) > > The jboss/redhat convention also requires a qualifier, CR, Alpha, Final > etc. +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if not JBoss Versioning then why not?

>> 2) A scheduled release: >> a) is a planned release, with a set of significant changes >> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to >> 0.5.0) >> c) gets a dedicated branch from master Why? Esp. why don't you keep things in master as long as possible and create those 0.4.x maintenance branches only when they are really needed? Actually, what is the role of master branch in your plan?

>> d) gets tagged on the branch Why not on master (if possible in the given situation)?

>> e) gets full release notes, JIRA, email communication, blog >> f) bits are published to JBoss Nexus and Github > > Don't think we should create a branch for the sake of it - if required > (i.e. for a patch) then can be created from the tag. >> 3) A patch release >> a) needed to address urgent bugs or regression between scheduled >> releases >> b) is an increment in the PATCH version (eg. 0.4.2) >> c) no dedicated branch, patches are applied to the branch of a >> 'scheduled >> release' >> d) gets tagged on the working branch >> e) no release notes, blog posts, or similar communication; the only >> official communication will be a list of JIRAs fixed >> f) bits published to JBoss Nexus and Github >> g) all the code fixes will be applied retroactively to master > > Not sure we are meant to release artifacts for patches? I thought patches > are only for product. Community would need to build from source if they > required these releases. > > Regards > Gary > >> >> >> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. Why one a month? Is there a way for me to find out at any point in time when will the next Metrics release happen? E.g. ATM it would be very helpful to know when is 0.3.5 coming? Note that rather than waiting days for the polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 coming today to be able to work on its integration into Hawkular.

Thanks, -- P >> The >> 'patch releases' will be created on a need basis and only if there are >> JIRAs >> reported against the 'scheduled release' or 'patch release' that need to >> be >> addressed before the next 'scheduled release'. One goal with the patch >> releases is to avoid publish a huge number of them in a short amount of >> time >> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; >> they >> will continue to get published from the code in the master branch. >> >> >> It would be great if all the projects converge on a similar process. I >> recognize that due to different maturity levels that might not be >> practical >> now for everybody, but it would be huge win for the entire Hawkular to >> make >> even small steps in the same direction. >> >> >> >> Thank you, >> Stefan Negrea >> >> Software Engineer >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

----- Original Message ----- > From: "Peter Palaga" <ppalaga(a)redhat.com&gt; > To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; > Sent: Monday, June 15, 2015 3:19:24 AM > Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components > > Hi Stefan, thanks for informing us how you will be doing things. It > would be nice to hear more about your motivations for these particular > decisions - see my "why"s inline. > > On 15/06/15 08:46, Gary Brown wrote: >> Hi Stefan >> >> ----- Original Message ----- >>> Hello Everybody, >>> >>> Had some great conversations and feedback this week about the release >>> process >>> for Hawkular Metrics. A few ideas emerged and this email is a summary of >>> the >>> process Hawkular Metrics will implement starting next release (expected as >>> soon as next week). >>> >>> Release Process: >>> 1) Use semver as the versioning standard (http://semver.org/) >> >> The jboss/redhat convention also requires a qualifier, CR, Alpha, Final >> etc. > > +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if > not JBoss Versioning then why not? Semver does not preclude JBoss versioning. When time comes Hawkular Metrics will adopt it but it's a bit too early now .... > >>> 2) A scheduled release: >>> a) is a planned release, with a set of significant changes >>> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to >>> 0.5.0) >>> c) gets a dedicated branch from master > > Why? Esp. why don't you keep things in master as long as possible and > create those 0.4.x maintenance branches only when they are really needed? > Actually, what is the role of master branch in your plan? The model with a branch is cleaner if the plan has the expectation of patch releases. Plus, it is very easy to know where to branch when a release is cut rather than 3 months later.

>>> d) gets tagged on the branch > > Why not on master (if possible in the given situation)? Not possible. The commit with the version will only live in release branch. > >>> e) gets full release notes, JIRA, email communication, blog >>> f) bits are published to JBoss Nexus and Github >> >> Don't think we should create a branch for the sake of it - if required >> (i.e. for a patch) then can be created from the tag. > >>> 3) A patch release >>> a) needed to address urgent bugs or regression between scheduled >>> releases >>> b) is an increment in the PATCH version (eg. 0.4.2) >>> c) no dedicated branch, patches are applied to the branch of a >>> 'scheduled >>> release' >>> d) gets tagged on the working branch >>> e) no release notes, blog posts, or similar communication; the only >>> official communication will be a list of JIRAs fixed >>> f) bits published to JBoss Nexus and Github >>> g) all the code fixes will be applied retroactively to master >> >> Not sure we are meant to release artifacts for patches? I thought patches >> are only for product. Community would need to build from source if they >> required these releases. >> >> Regards >> Gary >> >>> >>> >>> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. > > Why one a month? > Is there a way for me to find out at any point in time when will the > next Metrics release happen? E.g. ATM it would be very helpful to know > when is 0.3.5 coming? Note that rather than waiting days for the > polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 > coming today to be able to work on its integration into Hawkular. There will be no other releases besides scheduled and patch releases.And this process will start with the next release (0.4.0) which will most likely happen this week. The one month timeline is what works currently for Hawkular Metrics. If you want up to date changes for Hawkular Metrics please use timed snapshots. Here is the list for 0.3.5:

http://origin-repository.jboss.org/nexus/content/repositories/public/org/... Thank you, Stefan > > Thanks, > > -- P > >>> The >>> 'patch releases' will be created on a need basis and only if there are >>> JIRAs >>> reported against the 'scheduled release' or 'patch release' that need to >>> be >>> addressed before the next 'scheduled release'. One goal with the patch >>> releases is to avoid publish a huge number of them in a short amount of >>> time >>> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; >>> they >>> will continue to get published from the code in the master branch. >>> >>> >>> It would be great if all the projects converge on a similar process. I >>> recognize that due to different maturity levels that might not be >>> practical >>> now for everybody, but it would be huge win for the entire Hawkular to >>> make >>> even small steps in the same direction. >>> >>> >>> >>> Thank you, >>> Stefan Negrea >>> >>> Software Engineer >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

----- Original Message ----- > From: "Peter Palaga" <ppalaga(a)redhat.com&gt; > To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; > Sent: Monday, June 15, 2015 9:00:36 AM > Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components > > Hi Stefan, inline... > > On 15/06/15 14:56, Stefan Negrea wrote: >> >> >> ----- Original Message ----- >>> From: "Peter Palaga" <ppalaga(a)redhat.com&gt; >>> To: "Discussions around Hawkular development" >>> <hawkular-dev(a)lists.jboss.org&gt; >>> Sent: Monday, June 15, 2015 3:19:24 AM >>> Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + >>> Components >>> >>> Hi Stefan, thanks for informing us how you will be doing things. It >>> would be nice to hear more about your motivations for these particular >>> decisions - see my "why"s inline. >>> >>> On 15/06/15 08:46, Gary Brown wrote: >>>> Hi Stefan >>>> >>>> ----- Original Message ----- >>>>> Hello Everybody, >>>>> >>>>> Had some great conversations and feedback this week about the release >>>>> process >>>>> for Hawkular Metrics. A few ideas emerged and this email is a summary of >>>>> the >>>>> process Hawkular Metrics will implement starting next release (expected >>>>> as >>>>> soon as next week). >>>>> >>>>> Release Process: >>>>> 1) Use semver as the versioning standard (http://semver.org/) >>>> >>>> The jboss/redhat convention also requires a qualifier, CR, Alpha, Final >>>> etc. >>> >>> +1 for https://developer.jboss.org/wiki/JBossProjectVersioning and if >>> not JBoss Versioning then why not? >> >> Semver does not preclude JBoss versioning. When time comes Hawkular Metrics >> will adopt it but it's a bit too early now .... >> >>> >>>>> 2) A scheduled release: >>>>> a) is a planned release, with a set of significant changes >>>>> b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to >>>>> 0.5.0) >>>>> c) gets a dedicated branch from master >>> >>> Why? Esp. why don't you keep things in master as long as possible and >>> create those 0.4.x maintenance branches only when they are really needed? >>> Actually, what is the role of master branch in your plan? >> >> The model with a branch is cleaner if the plan has the expectation of patch >> releases. Plus, it is very easy to know where to branch when a release is >> cut rather than 3 months later. > > Once again: could you please sum up in a single sentence what should > happen in master? > > FWIW, I have understood already that tagging anything is not a kind of > thing allowed in master. > > To the very opposite, I am convinced that tags are very useful in master > - they mark very important milestones in the history and they naturaly > mark points where the histories of maintenance branches diverge from > master, if they exist or where to fork from master when there is a need > to create a maintenance branch. > > I looked at RHQ and I must say I do not like it. > >>>>> d) gets tagged on the branch >>> >>> Why not on master (if possible in the given situation)? >> >> Not possible. The commit with the version will only live in release branch. >> >>> >>>>> e) gets full release notes, JIRA, email communication, blog >>>>> f) bits are published to JBoss Nexus and Github >>>> >>>> Don't think we should create a branch for the sake of it - if required >>>> (i.e. for a patch) then can be created from the tag. >>> >>>>> 3) A patch release >>>>> a) needed to address urgent bugs or regression between scheduled >>>>> releases >>>>> b) is an increment in the PATCH version (eg. 0.4.2) >>>>> c) no dedicated branch, patches are applied to the branch of a >>>>> 'scheduled >>>>> release' >>>>> d) gets tagged on the working branch >>>>> e) no release notes, blog posts, or similar communication; the only >>>>> official communication will be a list of JIRAs fixed >>>>> f) bits published to JBoss Nexus and Github >>>>> g) all the code fixes will be applied retroactively to master >>>> >>>> Not sure we are meant to release artifacts for patches? I thought patches >>>> are only for product. Community would need to build from source if they >>>> required these releases. >>>> >>>> Regards >>>> Gary >>>> >>>>> >>>>> >>>>> Hawkular Metrics will keep 'scheduled releases' at roughly one a month. >>> >>> Why one a month? >>> Is there a way for me to find out at any point in time when will the >>> next Metrics release happen? E.g. ATM it would be very helpful to know >>> when is 0.3.5 coming? Note that rather than waiting days for the >>> polished 0.3.5, we'd be happier with a not-so-polished 0.3.5.Alpha1 >>> coming today to be able to work on its integration into Hawkular. >> >> >> There will be no other releases besides scheduled and patch >> releases.And this process will start with the next release (0.4.0) which >> will >> most likely happen this week. The one month timeline is what works >> currently for Hawkular Metrics. > > >> If you want up to date changes for Hawkular Metrics please use timed >> snapshots. Here is the list for 0.3.5: > > Am I understanding you right that you do not plan to release 0.3.5? > > In this branch https://github.com/hawkular/hawkular/tree/metrics-next, > we wait for 0.3.5 that would include the fix of the CORS bug provided to > Metrics by Viliam. I hope that fulfills your definition of patch release > (well, except that your definition is valid since next week of course)? > > We hereby kindy ask for 0.3.5 as soon as possible, because our branch is > aging and we need to bring it to master as soon as possible. Please note > that we cannot use a snapshot (timestamped or not) in hk master. You are correct, 0.3.5 will never be released. The next version according to this new release plan is 0.4.0.

And it should come sometimes this week, if we wrap this version in a good way. But this is versioning minutia. If you need to test with fixed code, that is available today and it was available since the fix was added on the master branch. Until the release is available please use the link below and pick a timed snapshot.

> > Thanks, > > Peter > >> http://origin-repository.jboss.org/nexus/content/repositories/public/org/... >> >> >> Thank you, >> Stefan >> >>> >>> Thanks, >>> >>> -- P >>> >>>>> The >>>>> 'patch releases' will be created on a need basis and only if there are >>>>> JIRAs >>>>> reported against the 'scheduled release' or 'patch release' that need to >>>>> be >>>>> addressed before the next 'scheduled release'. One goal with the patch >>>>> releases is to avoid publish a huge number of them in a short amount of >>>>> time >>>>> (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; >>>>> they >>>>> will continue to get published from the code in the master branch. >>>>> >>>>> >>>>> It would be great if all the projects converge on a similar process. I >>>>> recognize that due to different maturity levels that might not be >>>>> practical >>>>> now for everybody, but it would be huge win for the entire Hawkular to >>>>> make >>>>> even small steps in the same direction. >>>>> >>>>> >>>>> >>>>> Thank you, >>>>> Stefan Negrea >>>>> >>>>> Software Engineer >>>>> >>>>> _______________________________________________ >>>>> hawkular-dev mailing list >>>>> hawkular-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>>> >>>> _______________________________________________ >>>> hawkular-dev mailing list >>>> hawkular-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>>> >>> >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >>> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

When qualifiers will become relevant will add them to the version. Semver does not preclude the use of qualifiers, but Hawkular Metrics does not require qualifies at this time.

Hello Everybody, Had some great conversations and feedback this week about the release process for Hawkular Metrics. A few ideas emerged and this email is a summary of the process Hawkular Metrics will implement starting next release (expected as soon as next week). Release Process: 1) Use semver as the versioning standard (http://semver.org/) 2) A scheduled release: a) is a planned release, with a set of significant changes b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0) c) gets a dedicated branch from master d) gets tagged on the branch e) gets full release notes, JIRA, email communication, blog f) bits are published to JBoss Nexus and Github 3) A patch release a) needed to address urgent bugs or regression between scheduled releases b) is an increment in the PATCH version (eg. 0.4.2) c) no dedicated branch, patches are applied to the branch of a 'scheduled release' d) gets tagged on the working branch e) no release notes, blog posts, or similar communication; the only official communication will be a list of JIRAs fixed f) bits published to JBoss Nexus and Github g) all the code fixes will be applied retroactively to master Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The 'patch releases' will be created on a need basis and only if there are JIRAs reported against the 'scheduled release' or 'patch release' that need to be addressed before the next 'scheduled release'. One goal with the patch releases is to avoid publish a huge number of them in a short amount of time (eg. 2 per day). This does not impact at all the release for SNAPSHOTS; they will continue to get published from the code in the master branch. It would be great if all the projects converge on a similar process. I recognize that due to different maturity levels that might not be practical now for everybody, but it would be huge win for the entire Hawkular to make even small steps in the same direction.

Thank you, Stefan Negrea Software Engineer _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

f) bits are published to JBoss Nexus and Github

From: "Thomas Segismont" <tsegismo(a)redhat.com&gt; To: hawkular-dev(a)lists.jboss.org Sent: Monday, June 15, 2015 3:21:40 AM Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components Le 12/06/2015 22:45, Stefan Negrea a écrit : > f) bits are published to JBoss Nexus and Github About Gihub releases page: can you make sure to upload the ptrans distribution zip, not the ptrans.jar file? The ptrans.jar file alone is useless. Also, could you share the release process doc somewhere (internally)? So that we can still release if you broke your leg :-) Don't worry it won't happen!

_______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev