<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/30/2013 07:30 PM, Rob Stryker
wrote:<br>
</div>
<blockquote cite="mid:5249B520.80105@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">If the developer does not commit
anything to that repo, then it does not need a version bump.</div>
</blockquote>
I tend to disagree here: finishing a release is also preparing the
next one. When version x.y.z is released there shouldn't be any
other build creating an x.y.z version on an active dev stream.<br>
So IMO, although it indeed does not provide immediate value for
developers, bumping version makes it clear to anyone consuming
directly code from repository that this is after the release. In
that case, anyone includes the jbosstools and devstudio aggregators.<br>
<br>
<blockquote cite="mid:5249B520.80105@redhat.com" type="cite">
<div class="moz-cite-prefix">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. <br>
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.<br>
</div>
</blockquote>
In general, making it a mandatory step just after a release makes
sure no-one forgets it later. The worst case is the next builds for
that stream are not used: versions got bump without added value.<br>
<br>
The maintenance effort of bumping release just after the release
(not waiting for a change) is the same as doing it later.<br>
The overall quality and maintainability for consumers is highly
improved by systematic version bump after release.<br>
<br>
IMO, cost of bumping version that will not get used after a release
< cost of maintenance effort for consumers. Just compare the time
it took you + me to write those mails compared to bumping versions.
If bumping versions takes longer that a mail thread, just tell me.
We can do something about it.<br>
<br>
<br>
One day, developers will have to deal with something like this:
<a class="moz-txt-link-freetext" href="http://blog.osgi.org/2013/09/baselining-semantic-versioning-made-easy.html">http://blog.osgi.org/2013/09/baselining-semantic-versioning-made-easy.html</a>
, which is quite strict. And then you'll wonder "why the hell did
the world become so strict?", and the answer will be "just because
you didn't bump your version systematically last year" ;) So I
really encourage all of you to make the last step of a release be
"bump version in case of next release on that stream".<br>
<br>
Cheers,<br>
<div class="moz-signature">-- <br>
Mickael Istria<br>
Eclipse developer at <a href="http://www.jboss.org/tools">JBoss,
by Red Hat</a><br>
<a href="http://mickaelistria.wordpress.com">My blog</a> - <a
href="http://twitter.com/mickaelistria">My Tweets</a></div>
</body>
</html>