commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL] Version number(s) for modular components
Date Thu, 01 Dec 2016 09:05:27 GMT
On Wed, 30 Nov 2016 10:23:37 +0000, Stian Soiland-Reyes wrote:
> Yeah, that could be the better way, with a branched off commit for 
> the
> "shrunk" project with a smaller <modules> list in the parent, then no
> particular flags are needed to build from the resulting tag or source 
> repo.
>
> I initially planned to do so within the Taverna project (before we 
> moved to
> ASF), as it could mean smaller releases and avoiding updating OSGi
> coordinates for no-change. It turned out to alienate the rest of the 
> team
> as then releasing become even more special, particularly if more than 
> one
> submodule needed updating. After moving to ASF we had to do release
> artifacts (not just tags and Maven repo) and we abandoned this idea 
> and had
> to bite the bullet to release all modules every time.

IIUC, it then makes it easier for the RM, not the users (especially
those who have to upgrade for "no-change").

I've no problem with that; but let's just say it the way it is.

> As an example of projects doing the partial, look at the Clerezza 
> project
> which practices this using alternative release parents and dists; as 
> an
> outsider I find it a bit difficult to understand what of the project 
> has
> been released where (or at all), and which versions go together.

I was not considering a way to make it more difficult for users:
either they don't touch anything, or they upgrade; in the latter
alternative, a few lines in the release notes tell them what is
the last version of each module, and by convention, only that
combination would be "supported".

> Commons components are luckily small, so I think it could be done - 
> but
> only IF NEEDED, rather than as general practice.

In what cases would you consider it is needed?
In what cases is it allowed?
In what cases is it forbidden?

The discussion triggered by the proposal was meant define
clear rules, with some justification for them in order to curb
speculation.

But the replies did not clearly demonstrate how the proposal was
bad.

In this particular case, I'd have nothing against an argument of
authority, but is should be stated as such.
Obviously, there are limits to consensus-based policy, unless
consensus means that people don't care about the rationale of
their choices.
In that case, it would be more effective to just have a majority
vote to which anyone can then refer, rather than having endless
discussions; some saying it's OK, sometimes, and others saying
they are against, always.

> There is also the consideration of operation system distributions 
> like
> Debian who prefer a single source archive or tag for the whole 
> project (and
> no dual versions) - varying this per release means they are going to 
> not
> update correctly. Several commons component (including math3) are 
> already
> in Debian.

It could be a rationale for restricting what is possible.

But I don't really understand "dual versions".
In the proposal, the project's version would always be unique;
it is supplemented with a version specific to each of its
modules (i.e. a version is attached to a module/artefact); one
of these modules could be, by definition, the "distribution"
(as I've noticed several projects do), whose version would be
incremented in the same way as is done now for the "project".

This would indeed be just an additional convention!
And if it's the same for all "Commons" project, the better:
common build instructions can be published and common tools
defined in the parent project.[1]

Regards,
Gilles

[1] Cf. my questions for creating aggregate (i.e. "distribution")
     artefacts for the release of "Commons RNG"; from the answers
     I got, I still could not generate all the required files!

>
> On 30 Nov 2016 9:04 am, "Gilles" <gilles@harfang.homelinux.org> 
> wrote:
>
>> On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
>>
>>> What if a feature was added to the maven-release-plugin to release 
>>> a
>>> subset
>>> of submodules? I wonder how feasible that would be.
>>>
>>
>> When I thought of independent module releases, I assumed that
>> it would just be a matter of excluding some of the "<module>"
>> sections in the (parent) POM.  [That seemed to work for making
>> the Jenkins build pass on Java 6 while the "commons-rng-examples"
>> requires Java 7.]
>>
>> Gilles
>>
>> On 28 November 2016 at 19:00, Jörg Schaible <joerg.schaible@gmx.de> 
>> wrote:
>>>
>>> Gilles wrote:
>>>>
>>>> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>>>> >> Gilles,
>>>> >>
>>>> >> If you try to do this you are going to get very frustrated with
>>>> >> Maven. You cannot use the Maven Release plugin if all the 
>>>> versions
>>>> >> are
>>>> >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes

>>>> very
>>>> >> little sense to have them be out of sync. If you don’t use the
>>>> >> release
>>>> >> plugin then you will have to come up with some custom release
>>>> >> mechanism that somehow can only release a portion of your 
>>>> project.
>>>> >> This is going to get rather messy as you will constantly be 
>>>> updating
>>>> >> the parent pom to increment versions and require that to be 
>>>> released
>>>> >> along with the modules you are releasing - which means your 
>>>> other
>>>> >> modules really need to be updated to reflect the new parent 
>>>> version.
>>>> >>
>>>> >> To be honest, I did what you are suggesting at a former 
>>>> employer. We
>>>> >> eventually stopped and synchronized the versions of all the 
>>>> modules.
>>>> >> It simply wasn’t worth the effort to have all the versions be
>>>> >> different and the only real cost was releasing components with 
>>>> new
>>>> >> versions that hadn’t changed.
>>>> >
>>>> > Thanks for the testimony.
>>>> > Even if I have no clue how the version string causes a problem,
>>>> > I can readily concede that we can be constrained in how to 
>>>> manage
>>>> > a project because of the shortcomings of some tool.
>>>>
>>>> There is no no short coming, you can do otherwise, but if you 
>>>> follow
>>>> conventions Maven makes your life easy (Maven is all about 
>>>> conventions).
>>>> However, the release process described in rng does not use the 
>>>> release
>>>> plugin, so the point is moot.
>>>>
>>>> > Out of curiosity, is there an alternative (to maven?) that would
>>>> > not suffer from this limitation?
>>>>
>>>> It's not the tool we're discussing.
>>>>
>>>> Cheers,
>>>> Jörg
>>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message