<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 11:20 AM, Max Rydahl
Andersen wrote:<br>
</div>
<blockquote cite="mid:20130930092005.GJ9638@slowbeard.local"
type="cite">not sure I follow you fully here - which category.xml
and what kind of version ranges would you set ?
<br>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:20130930092005.GJ9638@slowbeard.local"
type="cite">
<blockquote type="cite">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).
<br>
</blockquote>
Because you want CI == Release builds, right ? Thats just not very
feasible wit p2/tycho :/
<br>
</blockquote>
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.<br>
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.<br>
<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>