commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: [ALL] Version number(s) for modular components
Date Sun, 27 Nov 2016 10:48:04 GMT
I think Gilles' reasoning is sound for semantic versioning and releases, in
line with OSGi principles. However I think that would be better suited in a
large or enterprise project with mainly internal usersnpf the libraries
that can play along, not in Apache Commons which are making general
availability libraries for the whole Java community.

So I'm afraid I agree with the quorum here, let's keep it simple with a
single version across modules - it is so much easier for downstream users
if we make the version in the distribution match the tag, which should
match every module (and also the OSGi package version)

Users with Maven can then just have a single $ property
to update and it all plays along, as tested in our release candidate.

Having to figure out the internal release policies and selecting across
many different source releases is not just a barrier to use, but also for
inviting new collaborators, they may struggle to know what to rebuild when
fixing a bug.

Another convenience argument for co-releasing is that the <dependencies>
section will pull the latest friends, users won't have to manage each
version to update, unless they want to deliberately stay behind "at own
risk" (Commons won't have tested that combination)

It does mean we sometimes get "pointless" upgrades on some modules where
nothing has changed. As long as we are not claiming major/breaking changes,
and don't use restricting (version,ranges] I don't think there is a big
problem with that.

The cases Gilles mention that is very much a potential scenario is where a
-utils module does breaking changes, but the -api module has not broken
anything. I think here we can be more lax about our package/artifact name
change rule, so you *could* release foo-api 2.0.0 and foo-utils2 2.0.0.  If
foo-api later breaks, that would be foo-api3 3.0.0 (there was never a
foo-api2) and foo-utils3 3.0.0 (not the very confusing double versioned
foo3-utils2! )

On 26 Nov 2016 10:49 pm, "Jörg Schaible" <> wrote:

> Gary Gregory wrote:
> > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <>
> > wrote:
> >
> >> Sorry, for me this is going down the wrong road. For me different
> >> versions mean different components. Allowing multiple versions for
> >> modules in one component will exactly open the can of worms Gilles
> >> described below. We had that already with Jakarta.
> >>
> >
> > +1 and we do not need a Commons within Commons.
> >
> > For the case:
> >
> >   commons-modproj-foo-1.0
> >   commons-modproj-bar-1.1
> >
> > You'd just release
> >
> >   commons-modproj-foo-1.0
> >   commons-modproj-bar-1.0
> >
> > and then
> >
> >   commons-modproj-foo-1.1
> >   commons-modproj-bar-1.1
> >
> > If nothing has changed in commons-modproj-foo between 1.0 and 1.1, then
> > that's fine. You just get all your matching modules and you are done.
> >
> >
> >> I still propose commons-rng-tools as separate component. Because of this
> >> mail. KISS.
> >>
> >
> > I'm not even in favor of that. Commons is already loose ecosystem of
> > components, having sibling components will fog things up IMO. It's not
> > just what's compatible with what according to some guidelines, it's more
> > what has been tested with what so I can know for sure what will work.
> When
> > I get Commons Foo 1.3 and it has 10 modules, I know it's all MEANT to
> work
> > together, I KNOW it was all BUILT and TESTED together.
> >
> > Just keep it all in one component and make user's life easy.
> We already have dbcp depending heavily on pool.
> - Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message