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(a)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