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 Sun, 27 Nov 2016 21:11:27 GMT
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).

 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.

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
View raw message