Hi Reto,
Unfortunately I have no clear vision on which direction to go. I guess
this is mainly caused by my focus on the rdf.* artefacts.
Let me try to sum it up:
1) Release all and release often
pros:
- For us this is probably easiest to do (from release perspective)
- The whole thing works together (from user perspective)
cons:
- Re-releasing modules with new version numbers without actual changes.
- Whole thing has to work together before being able to release
(from dev perspective)
2) Release individual components
pros:
- Only release what has changed. Small chunks.
- easier to release often
cons:
- Quite a hassle in the current project structure
- Users have to mix and match individual artefacts themselves.
There are probably some other pros and cons as well for each of these.
However I was wondering if there maybe is something in between. Like
instead of releasing all individual components, releasing larger
functionally separate chunks. For instance (this is just an example):
Rdf, Web, Platform, Utils and maybe a few others.
Does this make any sense?
Regards,
Minto
Reto Gmür schreef op 24-8-2014 18:05:
> Hi Minto, Hasan, all,
>
> How do we want to proceed on this. We have two incompatible proposals and
> an inpractical status quo. Do we want to have a vote?
>
>
> Cheers,
> Reto
>
>
> On Tue, Aug 19, 2014 at 10:06 PM, Reto Gmür <[email protected]> wrote:
>
>>
>>
>> On Sun, Aug 10, 2014 at 11:37 AM, Minto van der Sluis <[email protected]>
>> wrote:
>>
>>> Reto Gmür schreef op 8-8-2014 14:02:
>>>> On Thu, Aug 7, 2014 at 2:45 PM, Minto van der Sluis <
>>> [email protected]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>> Independently of this question I think we should re-discus the release
>>>>>> process. I consider the release process as it is now as problematic
>>>>> for the
>>>>>> following reasons:
>>>>>> 1. When releasing a module we can either release all dependent
>>> modules
>>>>>> as well or move the dependencies back to the last released version.
>>> With
>>>>>> the first approach we end up releasing modules that did not change,
>>> with
>>>>>> the latter we have to make sure that there was indeed no relevant
>>>>> change in
>>>>>> the module or in any other module reached via this dependency.
>>>>>> 2. When releasing multiple modules, those modules that are not
>>> part of
>>>>>> the release have to be removed from reactor and deleted in the release
>>>>>> branch, otherwise they will be part of the source-zip. As after the
>>>>> release
>>>>>> we want to merge back the changes to the version number to master, we
>>>>> have
>>>>>> to do a complicated selective merge as we don’t want to merge back the
>>>>>> removal of modules nor the downgrading of dependencies.
>>>>>>
>>>>> Looking from a user perspective (as using clerezza components). I'd
>>>>> rather like all components to have the same version number. Like this I
>>>>> don't have to think about which component versions work together. I
>>>>> expect all component with the same version to work together well. In my
>>>>> opinion this is option 1.
>>>>>
>>>> No that's not option A ("1" denotes a problem, not an option in my
>>> original
>>>> mail). Option A is that when a module is changed and released all
>>>> /dependent/ modules are released too. Even though I see the benefit
>>> from a
>>>> user perspective, releasing all modules on every change is not an
>>> option in
>>>> my opinion, because:
>>>> - it would unnecessarily float maven central
>>> Depends on how often you intend to release.
>>>> - releases are ideally small as this massively increases changes they
>>> get
>>>> properly reviewed
>>> This remains to be seen. Have a look at DataNucleus which is also a
>>> large project. Except for maybe power users it is easier to upgrade a
>>> single version for everything than multiple version for individual
>>> components.
>>>
>>>
>>> http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.datanucleus%22%20AND%20v%3A%224.0.1%22
>>>
>> Ok, that's 37 artifacts. Clerezza has currently around 200 artifacts.
>>
>> Also I get the impression that the modules therr are more tightly related.
>> Having a global release policy for clerezza means that we have a major
>> update of all rdf modules even if they are actually unchanged but there was
>> an icompatible change with the shell component.
>>
>>
>>>> - it is important for external dependent project to see if the new
>>> versions
>>>> actually change something, an important security fix upstream would
>>> justify
>>>> an new downstream release
>>> This is what release notes are for.
>>>
>> Asking a user of say jaxrs.utils to go through release notes to see if
>> anything changed between version 0.67 and 3.4.2 doesn't seem very user
>> friendly, at least not to the user of jaxrs.utils who doesn't care about
>> rdf, the osgi platform or the shell.
>>
>>
>>>> - we should release often. It is fast and painless to do a release of
>>>> virtuoso.storage after you fixed a bug there. Releasing everything after
>>>> your bug fix in a module is significantly more work, especially if one
>>> of
>>>> the modules depends on an external SNAPSHOT version and thus cannot be
>>>> released as it is in the master branch.
>>> Define release often. Is this after a single fix? Or is this after
>>> grouping a number of fixes. Or maybe based on a time schedule. For
>>> instance once a month. The question then remains: When are fixes
>>> important enough to break this schedule?
>>>
>> Pretty much after a single fix. Anything important enough that users can
>> benefit from. So that's pretty much everything but a typo in an error
>> message. Delaying the release in such a case is imho justified only if all
>> of the following are true:
>> - the fix is relatively unimportant (e.g. autocompletions works in some
>> more situations, performance improvement)
>> - some more improvements of that will be completed in the next weeks
>> - there no unreleased improvement in that module oldert than, say 2 month.
>>
>>
>>
>>>> - it doesn't work for the "benign" circular dependecies we have, e.g.
>>> the
>>>> pladoc plugin depends on many project that in turn use the plugin, this
>>>> only works by the development version depending on a released version of
>>>> the other.
>>> Seems like there is room for improvement here. ;-)
>>>
>> The circular dependencies cannot be avoided (if you think it can, bring
>> your proposal forward). But I have t admit they aren't an impediment for
>> global versioning. Our maven plugins would simply depend on the latest
>> released version of the modules (while everything else depends on the
>> current (snaphsot) version).
>>
>> Cheers,
>> Reto
>>
>>
>>>>
>>>>> I don't mind about unchanged components being rebuild with a newer
>>>>> version. Actually I prefer it like this since it gives me confidence
>>> for
>>>>> the reason I gave before (everything with the same version works well
>>>>> together).
>>>>>
>>>> Assuming we have reasonable integration tests this confidence is
>>> justified.
>>>> Now you would have to check in a tested launcher. Things get easier if
>>> you
>>>> use clerezza features as they should provide compatible sets of
>>> artifacts.
>>>> We could also provide an pom-project to be used as scope-import
>>> dependency
>>>> in the dependency-management section providing compatible versions.
>>>>
>>>>
>>>>> To me its one of the first decisions we have to make.
>>>>> [a] Release the whole with a single version number
>>>>> [b] Release individual component with their own version number.
>>>>>
>>>>> I favour option [a]. Also option [a] makes using the maven versions
>>>>> plugin a lot easier.
>>>>>
>>>> The maven release plugin can be used quite easily on a single module.
>>> Try
>>>> it out on virtuoso-storage where I think you recently fixed a bug.
>>>>
>>>> Cheers,
>>>> Reto
>>>>
>>>>
>>>>> Who else?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Minto
>>>>>
>>>
>>> --
>>> ir. ing. Minto van der Sluis
>>> Software innovator / renovator
>>> Xup BV
>>>
>>> Mobiel: +31 (0) 626 014541
>>>
>>>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
