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" <gil...@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.schai...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
