commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [ALL] Version number(s) for modular components
Date Sun, 27 Nov 2016 13:12:23 GMT
I'm also in the "one-version per repository"-camp.

Benedikt

Stian Soiland-Reyes <stain@apache.org> schrieb am So., 27. Nov. 2016 um
11:48 Uhr:

> 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 $commons.foo.versiom 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" <joerg.schaible@gmx.de> wrote:
>
> > Gary Gregory wrote:
> >
> > > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <joerg.schaible@gmx.de>
> > > 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: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

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