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.
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev