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

[Nick Boldt]

If we want to support the idea of a project having released its bits to 
a more stable URL than the usual /builds/staging/<JOB_NAME>/ location so 
as to lock down its contribution, we can already do that, and for some 
projects (eg., freemarker and gwt) we have *ALREADY* followed the JBTIS 
model of "put static URLs into the composite*.xml files from which the 
aggregate is built". This works, and it's a great way to reuse older 
unchanged content (the GWT stuff we have in JBT 4.1.0 is from JBT 4.0, 
as it's still unchanged).

HOWEVER...

That doesn't solve the issue of having a subcomponent *unchanged* when 
the rest of the component *HAS changed*.

In that case, we would need to release the unchanged subcomponents 
separate from the changed ones, so that we can composite/aggregate the 
correct versions and avoid the impending situation described below, 
where an end-user updating from JBT 4.1.0 to 4.1.1 would get two copies 
of the same plugin:

org.jboss.tools.runtime.core 2.1.0.Final-v20130717-0450-B102 (in 4.1.0)
org.jboss.tools.runtime.core 2.1.0.Final-v20131200-0000-Bxxx (in 4.1.1)

I would prefer to not start adding more github repos and jobs, but if 
these subcomponents are going to evolve more slowly than their 
containing projects, then maybe that's a necessary evil? Otherwise, we 
could simply have more than one update site produced by the project, and 
selectively publish them to different locations so the unchanged can be 
released to /updates/stable/kepler/<project>/<subcomponent>/<version> 
and the changing can remain in CI / staging, to be aggregated along with 
the rest of the stack.

On 09/30/2013 05:17 AM, Max Rydahl Andersen wrote:
> +1
>
> This is similar to what JBTIS does.
>
> /max
>
> On Fri, Sep 27, 2013 at 10:28:36AM -0700, Denis Golovin wrote:
>> I would prefer to have one place where we can configure what is included
>> into release.
>> Aggregate build seems to be a good candidate for this place. Why not
>> just point to exact version
>> 2.1.0.Final-v20130717-0450-B102 of runtime feature in aggregation update
>> site?
>>
>> Denis
>>
>> On 09/27/2013 09:10 AM, Nick Boldt wrote:
>>> In looking at the JBT 4.1.1.Alpha2 build [1], I see that some features
>>> have not yet changed since JBT 4.1.0.Final [2]. This is fine for a
>>> project like GWT or Freemarker, where the entire project is versioned
>>> the same way and we can simply include the previous .Final release, but
>>> for a subcomponent of a project, like the runtime component in
>>> jbosstools-base [3], this presents a question.
>>>
>>> [1]
>>> http://download.jboss.org/jbosstools/updates/nightly/core/4.1.kepler/
>>>
>>> [2] http://download.jboss.org/jbosstools/updates/stable/kepler/
>>>
>>> [3]
>>> http://download.jboss.org/jbosstools/builds/staging/jbosstools-base_41/all/repo/
>>>
>>>
>>> Currently, the base build [3] is producing this plugin:
>>>
>>> org.jboss.tools.runtime.core 2.1.0.Alpha2-v20130927-0137-B114
>>>
>>> But the JBT 4.1.1.Alpha2 build [1] contains this version, which is
>>> code-wise identical except for the qualifier change in the manifest.
>>>
>>> org.jboss.tools.runtime.core 2.1.0.Final-v20130717-0450-B102
>>>
>>> Where it becomes an issue is that when we start building 4.1.1.Final in
>>> November, we will be including both 2.1.0.Final-v20130717-0450-B102
>>> (from JBT 4.1.0.Final) and 2.1.0.Final-v20131200-0000-Bxxx (from JBT
>>> 4.1.1.Final). Since these are bitwise identical, there's no point making
>>> users update from an identical feature or plugin to a newer identical
>>> version.
>>>
>>> So how do we prevent the build from including a newer-versioned but
>>> identical feature or plugin?
>>>
>>> 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].
>>>
>>> [4]
>>> https://github.com/jbosstools/jbosstools-central/commit/16279020cbf872f4eac59a36a77df01edb2ed832
>>>
>>>
>>> Looking for feedback here -- is this a good idea?
>>>
>>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com