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

[Max Rydahl Andersen]

On Mon, Sep 30, 2013 at 07:38:32AM +0200, Mickael Istria wrote:
>On 09/27/2013 06:10 PM, Nick Boldt wrote:
>>The only thing I can currently think of is to *exclude* these features
>>from the base_41 update site [3] so that only the older version from [2]
>>will be included.
>>
>>This is basically the process I used to build JBT 4.1.0.1 - I excluded
>>everything from jbosstools-central's site/category.xml except the
>>feature which had actually changed [4].
>I don't find it very easy to deal with picked dependencies on the 
>producer's side. Choosing dependencies is IMO a responsibility of the 
>consumer (JBT aggregator).
>I tend to agree with Denis when he says that this should be something 
>set in aggregator. We should ask component leads which version of the 
>feature has to be aggregated (last build from branch, or last 
>release?).
>
>However, that also shows that all versions should be bumped after a 
>release, and this should be component's developer responsibility: when 
>you have x.y.z released, then immediate next commit is to move to 
>x.y.z+1 or x.y+1.0. Preparing versions for next stream is the last 
>step of a release, not the first of the next release, so it should be 
>done immediatly to prevent such issues.
>If we do that, then we can filter using version ranges in our 
>aggregator category.xml, which seems to be a very good trade-off 
>between control and flexibility.

not sure I follow you fully here - which category.xml and what kind of version ranges would you set ?

>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 :/

/max