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 <chtom...@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 <brit...@apache.org>
wrote:
>
> I'm also in the "one-version per repository"-camp.
>
> Benedikt
>
> Stian Soiland-Reyes <st...@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.schai...@gmx.de>
wrote:
>>>
>>> Gary Gregory wrote:
>>>
>>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible
<joerg.schai...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
