Re: [ee4j-pmc] git release tags

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Lukas Jungmann wrote on 11/28/18 07:15 AM:
> Hi,
> 
> On 11/28/18 1:05 AM, Bill Shannon wrote:
>> When we discussed this recently the consensus was that release tags
>> should be git annotated tags that use the release number as the tag
>> name.  (Yes, Markus, this is just a recommendation, not a requirement.)
>>
>> I decided to see if people are following the recommendation.  There
>> haven't been many GitHub releases created yet, but there are a lot of
>> tags, quite a few of which don't follow the recommendation.  The most
>> common divergence by far is to follow the release number with "-RELEASE".
>> This is probably intended to match the pattern "-M1" and "-RC1" for
>> milestone and release candidate releases.
> 
> agree that '-RELEASE' is not nice.
> 
> As we do not live in an ideal world, there are project repositories producing
> more than 1 "module"/release artifact(*). Using plain version number looks
> confusing to me in this case as well as it implies potential conflict if 2 (or
> more) modules would be released with same version number. What release tag name
> format would be recommended for these submodules? I can think of
> <version>-<module> or <module>-<version> with pure <version> being reserved for
> the main artifacts produced by particular repository.
> 
> There is also always an option to somehow remove the need of this discrepancy
> (ie split affected repos) but at least in case of jaxb-ri, it is, IMHO, to much
> work for a little gain. I know nothing about glassfish-fighterfish.

I think a best practice is to keep the version numbers of all subprojects
synchronized.  That might mean releasing updated versions of some artifacts
that have no actual changes other than the version number, but that's
probably ok.

If the version numbers of subprojects are wildly divergent, it's probably
best to split them into separate projects.

(And yes, there might be exceptions.)