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 21:19:16 GMT
Hello Gilles,

Gilles <gilles@harfang.homelinux.org> schrieb am So., 27. Nov. 2016 um
22:11 Uhr:

> On Sun, 27 Nov 2016 11:52:12 -0600, Matt Sicker wrote:
> > I think everything would be much easier to just maintain one version
> > per
> > repository. Besides, it would get confusing having multiple git tags
> > or svn
> > tags for different component versions, especially if a repository
> > uses
> > short tag names that only include the version number and not the
> > component
> > name.
>
> I do not follow what is being discussed here.
>
> In the "Commons Math" git repository, there is "MATH_3_X" branch that
> was explicitly created to release "another" version.
>
> My proposal is simply to extend it to each module, reflecting the
> the actual contents (what else?).
> A common version numbering is just misleading.


> I don't see what can of worms this suggestion is opening.
> On the other hand, I do see the nuisances caused by forcing the same
> version number on loosely related modules (one of which is reminded
> by Stian, quoted below).
>

You have asked for opinions - be prepared people don't agree with you.


>
>  From the outset, I've suspected that "RNG Utils" should be a separate
> component because of the different set of skills required to design,
> implement and test, say, "commons-rng-core" and "commons-rng-sampling".
>
> Upon being told that such a component would not be accepted, I resorted
> to make it a module, along with others, which were a Good Thing (TM)...
>
> But now I'm being told that having modules does not provide any more
> flexibility than a monolithic project!
>
> And then, to revert the changes brought about to achieve
> modularization!
> If it's a joke, it is not funny.
>
> IIUC, those issues were raised:
>   * Users could be at a loss as to which modules they can use together.
>     -> Isn't this solved by automatic dependency management nowadays?
>   * Users would not know what are the most recent release of each module
>     -> This would be mentioned in the release notes: even if a module is
>      not released (because it did not change), its latest version would
>      be referenced.
>   * Developers would not know what/where to fix.
>     -> Isn't that the purpose of having a source control system?
>
> I've still to see one use-case where it will cause a problem, while
> I've described several where the independent version numbering
> provides advantages.
>
> Incidentally, this is all supported by maven: IIUC, each modules has
> its
> own version number, and it cannot be inherited from the parent project.
>

Just because it is supported doesn't mean it is a good idea.


>
> Regards,
> Gilles
>
> >
> > On 27 November 2016 at 07:36, Rob Tompkins <chtompki@gmail.com>
> > wrote:
> >
> >> I forgot to mention that it seems to me that this (a singly versions
> >> block
> >> of code) is the fundamental "meaning" of what a repository is. I
> >> mean that
> >> in the sense that if you want separate separately versioned
> >> components,
> >> that is a direct argument for separate repositories.
> >>
> >> With that said, I'm not opposed to the conversation of enabling
> >> separately
> >> versioned portions of rng by pulling them out into other repos, but
> >> that
> >> bumps into the definition of a "commons" component.
> >>
> >> Either way these are just thoughts and not hard and fast rules. I
> >> don't
> >> feel overly tied to any position here.
> >>
> >> Cheers,
> >> -Rob
> >>
> >> > On Nov 27, 2016, at 8:12 AM, Benedikt Ritter <britter@apache.org>
> >> wrote:
> >> >
> >> > 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