[Hawkular-dev] Release Process - Hawkular Metrics + Components

[Thomas Heute]

On 06/15/2015 02:42 PM, Stefan Negrea wrote:
>
>
> ----- Original Message -----
>> From: "Gary Brown" <gbrown at redhat.com>
>> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
>> Sent: Monday, June 15, 2015 1:46:20 AM
>> Subject: Re: [Hawkular-dev] Release Process - Hawkular Metrics + Components
>>
>> 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.
>
> 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.

It is required.

>>
>>> 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
>>
>> 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.
>
> This model is not new, we've been tested it with RHQ and it worked well. It is good to have a permanent branch for some code if you expect to publish patch releases of that code.
>
>>
>>> 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.
>
> This is an implicit requirement from the discussions I've had last week. The need was to patch (with a single commit) a previous version of Hawkular Metrics for consumption in Hawkular. Since Hawkular proper needed to consume the patched bits, publishing is the only option. Also, from the way I framed a patch release, unless somebody needs to consume fixed bits, it will not happen. If it's just a bug that can be fixed in the next scheduled release, then no code changes will be made for the affected release.

You may still need to release more often/change schedule to satisfy the 
main consumer which is Hawkular.

Thomas

>
>
> Thank you,
> Stefan
>
>>
>> Regards
>> Gary
>>
>>>
>>>
>>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>