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

On 09/30/2013 07:30 PM, Rob Stryker wrote: 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. 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. 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. The maintenance effort of bumping release just after the release (not waiting for a change) is the same as doing it later. The overall quality and maintainability for consumers is highly improved by systematic version bump after release. 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. One day, developers will have to deal with something like this: http://blog.osgi.org/2013/09/baselining-semantic-versioning-made-easy.html , 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". Cheers, -- 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>