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 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev