[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]

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

As I said - if you are in one repository you get released together. Keep it simple.
Don't overoptimize if not really necessary.

>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

if setup of jobs wasn't a manual thing then this would be much less of an issue, right ? 

>, 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, 

That sounds to me be just the same or even more work if we had more repo/jobs since
then it would be handled even more differently depending on each component "inner movement" ?

>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.

Unless you tell me one of these base components are several ten/hundreds MB's of updates then i'm fine with each repository
being the granularity of updates. More important issues to fix than this IMO.

/max


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