[jbosstools-dev] How should we deal with components of projects which have not changed since JBT 4.1.0.Final (eg., jbosstools-base/runtime) ?

[Rob Stryker]

Versions should be bumped as part of the first commit after a release. 
So for example, say we branch, and branch is now what's going to be our 
major release, and master becomes our NEXT major release.,

If the developer does not commit anything to that repo, then it does not 
need a version bump. The version bump should be done in parallel with 
the very first change to the repo. If the user fixes a typo, and the 
component has not yet been version-bumped, then it must now be 
version-bumped, during that very first commit.

But of course repo-owners have the right to simply bump everything 
immediately after the branch if they feel safer doing it that way... if 
they feel like they need to so they don't forget to do it later.

On 09/30/2013 05:32 PM, Mickael Istria wrote:
> On 09/30/2013 11:20 AM, Max Rydahl Andersen wrote:
>> not sure I follow you fully here - which category.xml and what kind 
>> of version ranges would you set ?
> I'm saying that bundles and features version should be bumped just 
> after a release, and that aggregator category.xml should use version 
> range that match the stream [x.y.z,x.y.z+1) . So we control what 
> stream gets in.
>
>>> It appears that this use-case is covered by Tycho baseline 
>>> replacement mechanism. This mechanism currently can't work for us 
>>> until we have reproducible qualifiers (which I don't like).
>> Because you want CI == Release builds, right ? Thats just not very 
>> feasible wit p2/tycho :/
> No, it's just that it would be better if we would avoid creating new 
> bundles just because build date is different. That's the purpose of 
> whole baseline mechanism, re-use existing compatible builds from 
> release when it makes sense instead of creating the same bundle with 
> another timestamp.
> But I think it is indeed not necessary if components have a string 
> versioning and bump their versions after each release. In such case, 
> having a baseline comparator such a the version watch tool would be 
> enough. Rule would be: if same x.y.z than an existing release, but 
> with different qualifier, fail build telling developer to bump the 
> version.
>
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com> - My Tweets 
> <http://twitter.com/mickaelistria>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20131001/aede4bdb/attachment.html