You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2016/11/26 16:20:14 UTC
[ALL] Version number(s) for modular components
Hello.
As a follow-up of
http://markmail.org/message/jckbknphndecglns
and
http://markmail.org/message/f3g33kvevf52xohf
I summarize what I think should be allowed for versioning
modularized components of the "Commons" project.
Assume there are two modules in project "Commons ModProj":
commons-modproj-foo
commons-modproj-bar
Their respective "top-level package" would be:
org.apache.commons.modproj.foo
org.apache.commons.modproj.bar
I propose that versioning of the modules are independent
(as if they were different components).
As said in the referred posts, it would allow the version
numbers to reflect the actual state of each of the module.
For example, assume that this proposal is validated, and
that
commons-modproj-foo-1.0
commons-modproj-bar-1.1
were released.
Note: for the sake of exercising the version changes, all the
cases below happen in the sequence shown (ala "switch" with
"case" without "break").
=== Case (A) ===
We must release a non-BC upgrade of "bar".
Hence, we would release
commons-modproj-bar-2.0
with "top-level package"
org.apache.commons.modproj.bar2
Advantage: applications that only use module "foo" are unaffected.
=== Case (B) ===
Assume that "bar" depends on "foo".
-- Case (B1) --
We release a BC version of "foo":
commons-modproj-foo-1.1
* Case (B1+)
The upgrade consists of new features only.
Module "bar" is totally unaffected (what worked with foo-1.0
works the same with foo-1.1) and no new release of "bar2"
will happen.
Advantage: users of "bar2" only will not wonder whether they
should upgrade (if they did not intend to use new features,
there is no reason for them to upgrade).
* Case (B1-)
The upgrade consists of bug fixes.
Both modules will be released, i.e.
commons-modproj-foo-1.1.1
commons-modproj-bar2-2.0.1
This will trigger an upgrade for all users (who care about
correctness).
-- Case (B2) --
We release a non-BC version of "foo":
commons-modproj-foo2-2.0
with "top-level package"
org.apache.commons.modproj.foo2
* Case (B2+)
The upgrade is purely a re-design.
The development team is free to (major) release the new
"foo2-2.0" without having upgraded "bar2", i.e. latest "bar2"
(2.0.1) still uses "foo-1.1.1".
~ Case (B2+sync)
Team is able to provide, at time of release, a bridge and
release
commons-modproj-bar2-2.1
so that users of "bar2-2.1" will transparently use
"foo2-2.0"
(in place of "foo-1.1.1").
~ Case (B2+async)
Team is able to provide (or improve) the bridge later on,
i.e. release
commons-modproj-foo2-2.1
commons-modproj-bar2-2.2
so that users of "bar2" only will transparently use
"foo2-2.1"
(in place of "foo-1.1.1" or "foo2-2.0").
Advantages:
- Redesigned "foo" can be released without worrying about
upgrading "bar" (RERO).
- Users of "bar2" only can either not worry about upgrade,
or just update their version dependency (not changing a
single line of code).
* Case (B2++)
Previous re-design turned out to be sub-optimal.
A new major "foo" is released:
commons-modproj-foo3-3.0
with "top-level package"
org.apache.commons.modproj.foo3
[Same (non-)consequences for "bar2" as previous case.]
* Case (B2-)
An upgrade also contains bug-fixes.
A new major "foo" will be released, i.e.
commons-modproj-foo4-4.0
with "top-level package"
org.apache.commons.modproj.foo4
together with a new major "bar"
commons-modproj-bar3-3.0
with "top-level package"
org.apache.commons.modproj.bar3
Here the upgrade of "bar" will force its users to think
about whether they need to upgrade (whether they are
impacted by the bugs or they want to have support usually
provided for latest version only).
=== Case (C) ===
People want to completely redesign the whole "ModProj" functionality.
We can release
commons-modproj2-foo-1.0
commons-modproj2-bar-1.0
Their respective "top-level package" would be:
org.apache.commons.modproj2.foo
org.apache.commons.modproj2.bar
At this point we'd have these modules officially released:
commons-modproj-foo4-4.0
commons-modproj-bar3-3.0
commons-modproj2-foo-1.0
commons-modproj2-bar-1.0
all happily living together[1]; and improvements can be easily
exchanged among the different lines of development (e.g. via
"git" branches).
Obviously, the significant change is that version numbers are
tied to modules, not component. Does that pose a problem?[2]
[It should be clear that having the same version numbers for
"foo" and "bar" would be a pure coincidence.]
In particular, version and package changes are confined to
where code changes happen; they follow the development of
specific features (while non-impacted code is not forced to
adopt a version that is actually related to "foreign" code).
Another fundamental advantage, community-wise, is that it is
conducive to maintaining a good relationship among developers
even if they want to "scratch different itches".[3]
In effet, this scheme would allow to group codes by "broad"
subject while module management could be fine-grained,[4]
up to using specific version suffixes (such as "-dev" or
"-extras") to convey intended use or audience or level of
support...
Regards,
Gilles
[1] Provided the dependencies are correct of course.
[2] According to Stian, it does not (IIRC).
[3] Whereas the current scheme turned different POV into personal
fights, with punctual winners and losers (however gracefully
they think they can handle it) but an enduring overall loss
for the community.
[4] On a par with the varying levels of development (for whatever
reasons, such as lack of time or lack of contributors) of those
modules.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 26, 2016 at 9:28 AM, Rob Tompkins <ch...@gmail.com> wrote:
> I've always thought that versioning sat at a repository level. When you
> check out (or clone or whatever) code it feels counterintuitive to have
> several different potential versions floating around in what you just got.
> So I would argue for the general guideline of one repository, one overall
> version.
>
Exactly, as I wrote earlier, this proposed version salad is a guarantee for
confusing, what's compatible with what, what's been tested with what. Is
the build going to depend on a matrix of test jars and runtime jars to make
sure it all works?
In short:
- KISS: Keep it in one component, especially for 1.0! Even reconsider going
back to a single module. Or,
- Go TLP and do whatever you want.
Gary
> Cheers,
> -Rob
>
> > On Nov 26, 2016, at 12:06 PM, Jörg Schaible <jo...@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.
> >
> > I still propose commons-rng-tools as separate component. Because of this
> > mail. KISS.
> >
> > - Jörg
> >
> > Gilles wrote:
> >
> >> Hello.
> >>
> >> As a follow-up of
> >> http://markmail.org/message/jckbknphndecglns
> >> and
> >> http://markmail.org/message/f3g33kvevf52xohf
> >> I summarize what I think should be allowed for versioning
> >> modularized components of the "Commons" project.
> >>
> >> Assume there are two modules in project "Commons ModProj":
> >> commons-modproj-foo
> >> commons-modproj-bar
> >>
> >> Their respective "top-level package" would be:
> >> org.apache.commons.modproj.foo
> >> org.apache.commons.modproj.bar
> >>
> >> I propose that versioning of the modules are independent
> >> (as if they were different components).
> >>
> >> As said in the referred posts, it would allow the version
> >> numbers to reflect the actual state of each of the module.
> >> For example, assume that this proposal is validated, and
> >> that
> >> commons-modproj-foo-1.0
> >> commons-modproj-bar-1.1
> >> were released.
> >>
> >> Note: for the sake of exercising the version changes, all the
> >> cases below happen in the sequence shown (ala "switch" with
> >> "case" without "break").
> >>
> >> === Case (A) ===
> >>
> >> We must release a non-BC upgrade of "bar".
> >> Hence, we would release
> >> commons-modproj-bar-2.0
> >> with "top-level package"
> >> org.apache.commons.modproj.bar2
> >>
> >> Advantage: applications that only use module "foo" are unaffected.
> >>
> >> === Case (B) ===
> >>
> >> Assume that "bar" depends on "foo".
> >>
> >> -- Case (B1) --
> >> We release a BC version of "foo":
> >> commons-modproj-foo-1.1
> >>
> >> * Case (B1+)
> >> The upgrade consists of new features only.
> >> Module "bar" is totally unaffected (what worked with foo-1.0
> >> works the same with foo-1.1) and no new release of "bar2"
> >> will happen.
> >>
> >> Advantage: users of "bar2" only will not wonder whether they
> >> should upgrade (if they did not intend to use new features,
> >> there is no reason for them to upgrade).
> >>
> >> * Case (B1-)
> >> The upgrade consists of bug fixes.
> >> Both modules will be released, i.e.
> >> commons-modproj-foo-1.1.1
> >> commons-modproj-bar2-2.0.1
> >>
> >> This will trigger an upgrade for all users (who care about
> >> correctness).
> >>
> >> -- Case (B2) --
> >> We release a non-BC version of "foo":
> >> commons-modproj-foo2-2.0
> >> with "top-level package"
> >> org.apache.commons.modproj.foo2
> >>
> >> * Case (B2+)
> >> The upgrade is purely a re-design.
> >>
> >> The development team is free to (major) release the new
> >> "foo2-2.0" without having upgraded "bar2", i.e. latest "bar2"
> >> (2.0.1) still uses "foo-1.1.1".
> >>
> >> ~ Case (B2+sync)
> >> Team is able to provide, at time of release, a bridge and
> >> release
> >> commons-modproj-bar2-2.1
> >> so that users of "bar2-2.1" will transparently use
> >> "foo2-2.0"
> >> (in place of "foo-1.1.1").
> >>
> >> ~ Case (B2+async)
> >> Team is able to provide (or improve) the bridge later on,
> >> i.e. release
> >> commons-modproj-foo2-2.1
> >> commons-modproj-bar2-2.2
> >> so that users of "bar2" only will transparently use
> >> "foo2-2.1"
> >> (in place of "foo-1.1.1" or "foo2-2.0").
> >>
> >> Advantages:
> >> - Redesigned "foo" can be released without worrying about
> >> upgrading "bar" (RERO).
> >> - Users of "bar2" only can either not worry about upgrade,
> >> or just update their version dependency (not changing a
> >> single line of code).
> >>
> >> * Case (B2++)
> >> Previous re-design turned out to be sub-optimal.
> >>
> >> A new major "foo" is released:
> >> commons-modproj-foo3-3.0
> >> with "top-level package"
> >> org.apache.commons.modproj.foo3
> >>
> >> [Same (non-)consequences for "bar2" as previous case.]
> >>
> >> * Case (B2-)
> >> An upgrade also contains bug-fixes.
> >>
> >> A new major "foo" will be released, i.e.
> >> commons-modproj-foo4-4.0
> >> with "top-level package"
> >> org.apache.commons.modproj.foo4
> >> together with a new major "bar"
> >> commons-modproj-bar3-3.0
> >> with "top-level package"
> >> org.apache.commons.modproj.bar3
> >>
> >> Here the upgrade of "bar" will force its users to think
> >> about whether they need to upgrade (whether they are
> >> impacted by the bugs or they want to have support usually
> >> provided for latest version only).
> >>
> >> === Case (C) ===
> >>
> >> People want to completely redesign the whole "ModProj" functionality.
> >>
> >> We can release
> >> commons-modproj2-foo-1.0
> >> commons-modproj2-bar-1.0
> >>
> >> Their respective "top-level package" would be:
> >> org.apache.commons.modproj2.foo
> >> org.apache.commons.modproj2.bar
> >>
> >>
> >> At this point we'd have these modules officially released:
> >> commons-modproj-foo4-4.0
> >> commons-modproj-bar3-3.0
> >> commons-modproj2-foo-1.0
> >> commons-modproj2-bar-1.0
> >> all happily living together[1]; and improvements can be easily
> >> exchanged among the different lines of development (e.g. via
> >> "git" branches).
> >>
> >> Obviously, the significant change is that version numbers are
> >> tied to modules, not component. Does that pose a problem?[2]
> >> [It should be clear that having the same version numbers for
> >> "foo" and "bar" would be a pure coincidence.]
> >>
> >> In particular, version and package changes are confined to
> >> where code changes happen; they follow the development of
> >> specific features (while non-impacted code is not forced to
> >> adopt a version that is actually related to "foreign" code).
> >>
> >> Another fundamental advantage, community-wise, is that it is
> >> conducive to maintaining a good relationship among developers
> >> even if they want to "scratch different itches".[3]
> >>
> >> In effet, this scheme would allow to group codes by "broad"
> >> subject while module management could be fine-grained,[4]
> >> up to using specific version suffixes (such as "-dev" or
> >> "-extras") to convey intended use or audience or level of
> >> support...
> >>
> >>
> >> Regards,
> >> Gilles
> >>
> >> [1] Provided the dependencies are correct of course.
> >> [2] According to Stian, it does not (IIRC).
> >> [3] Whereas the current scheme turned different POV into personal
> >> fights, with punctual winners and losers (however gracefully
> >> they think they can handle it) but an enduring overall loss
> >> for the community.
> >> [4] On a par with the varying levels of development (for whatever
> >> reasons, such as lack of time or lack of contributors) of those
> >> modules.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Version number(s) for modular components
Posted by Charles Honton <ch...@honton.org>.
My experience suggests that the "one repository, one version" rule works best. This, however, does not solve the concern of allowing quick releases with multiple simultaneous features.
This concern is better solved with feature branches. Mainline branch, (“master”) must be releasable at any time and contains any bug fixes. All feature work is in a branch. Once the feature is ready, the branch can be merged into master and released. No feature should hold up releasing another independent feature nor bug fixes in the master branch.
chas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Rob Tompkins <ch...@gmail.com>.
I've always thought that versioning sat at a repository level. When you check out (or clone or whatever) code it feels counterintuitive to have several different potential versions floating around in what you just got. So I would argue for the general guideline of one repository, one overall version.
Cheers,
-Rob
> On Nov 26, 2016, at 12:06 PM, Jörg Schaible <jo...@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.
>
> I still propose commons-rng-tools as separate component. Because of this
> mail. KISS.
>
> - Jörg
>
> Gilles wrote:
>
>> Hello.
>>
>> As a follow-up of
>> http://markmail.org/message/jckbknphndecglns
>> and
>> http://markmail.org/message/f3g33kvevf52xohf
>> I summarize what I think should be allowed for versioning
>> modularized components of the "Commons" project.
>>
>> Assume there are two modules in project "Commons ModProj":
>> commons-modproj-foo
>> commons-modproj-bar
>>
>> Their respective "top-level package" would be:
>> org.apache.commons.modproj.foo
>> org.apache.commons.modproj.bar
>>
>> I propose that versioning of the modules are independent
>> (as if they were different components).
>>
>> As said in the referred posts, it would allow the version
>> numbers to reflect the actual state of each of the module.
>> For example, assume that this proposal is validated, and
>> that
>> commons-modproj-foo-1.0
>> commons-modproj-bar-1.1
>> were released.
>>
>> Note: for the sake of exercising the version changes, all the
>> cases below happen in the sequence shown (ala "switch" with
>> "case" without "break").
>>
>> === Case (A) ===
>>
>> We must release a non-BC upgrade of "bar".
>> Hence, we would release
>> commons-modproj-bar-2.0
>> with "top-level package"
>> org.apache.commons.modproj.bar2
>>
>> Advantage: applications that only use module "foo" are unaffected.
>>
>> === Case (B) ===
>>
>> Assume that "bar" depends on "foo".
>>
>> -- Case (B1) --
>> We release a BC version of "foo":
>> commons-modproj-foo-1.1
>>
>> * Case (B1+)
>> The upgrade consists of new features only.
>> Module "bar" is totally unaffected (what worked with foo-1.0
>> works the same with foo-1.1) and no new release of "bar2"
>> will happen.
>>
>> Advantage: users of "bar2" only will not wonder whether they
>> should upgrade (if they did not intend to use new features,
>> there is no reason for them to upgrade).
>>
>> * Case (B1-)
>> The upgrade consists of bug fixes.
>> Both modules will be released, i.e.
>> commons-modproj-foo-1.1.1
>> commons-modproj-bar2-2.0.1
>>
>> This will trigger an upgrade for all users (who care about
>> correctness).
>>
>> -- Case (B2) --
>> We release a non-BC version of "foo":
>> commons-modproj-foo2-2.0
>> with "top-level package"
>> org.apache.commons.modproj.foo2
>>
>> * Case (B2+)
>> The upgrade is purely a re-design.
>>
>> The development team is free to (major) release the new
>> "foo2-2.0" without having upgraded "bar2", i.e. latest "bar2"
>> (2.0.1) still uses "foo-1.1.1".
>>
>> ~ Case (B2+sync)
>> Team is able to provide, at time of release, a bridge and
>> release
>> commons-modproj-bar2-2.1
>> so that users of "bar2-2.1" will transparently use
>> "foo2-2.0"
>> (in place of "foo-1.1.1").
>>
>> ~ Case (B2+async)
>> Team is able to provide (or improve) the bridge later on,
>> i.e. release
>> commons-modproj-foo2-2.1
>> commons-modproj-bar2-2.2
>> so that users of "bar2" only will transparently use
>> "foo2-2.1"
>> (in place of "foo-1.1.1" or "foo2-2.0").
>>
>> Advantages:
>> - Redesigned "foo" can be released without worrying about
>> upgrading "bar" (RERO).
>> - Users of "bar2" only can either not worry about upgrade,
>> or just update their version dependency (not changing a
>> single line of code).
>>
>> * Case (B2++)
>> Previous re-design turned out to be sub-optimal.
>>
>> A new major "foo" is released:
>> commons-modproj-foo3-3.0
>> with "top-level package"
>> org.apache.commons.modproj.foo3
>>
>> [Same (non-)consequences for "bar2" as previous case.]
>>
>> * Case (B2-)
>> An upgrade also contains bug-fixes.
>>
>> A new major "foo" will be released, i.e.
>> commons-modproj-foo4-4.0
>> with "top-level package"
>> org.apache.commons.modproj.foo4
>> together with a new major "bar"
>> commons-modproj-bar3-3.0
>> with "top-level package"
>> org.apache.commons.modproj.bar3
>>
>> Here the upgrade of "bar" will force its users to think
>> about whether they need to upgrade (whether they are
>> impacted by the bugs or they want to have support usually
>> provided for latest version only).
>>
>> === Case (C) ===
>>
>> People want to completely redesign the whole "ModProj" functionality.
>>
>> We can release
>> commons-modproj2-foo-1.0
>> commons-modproj2-bar-1.0
>>
>> Their respective "top-level package" would be:
>> org.apache.commons.modproj2.foo
>> org.apache.commons.modproj2.bar
>>
>>
>> At this point we'd have these modules officially released:
>> commons-modproj-foo4-4.0
>> commons-modproj-bar3-3.0
>> commons-modproj2-foo-1.0
>> commons-modproj2-bar-1.0
>> all happily living together[1]; and improvements can be easily
>> exchanged among the different lines of development (e.g. via
>> "git" branches).
>>
>> Obviously, the significant change is that version numbers are
>> tied to modules, not component. Does that pose a problem?[2]
>> [It should be clear that having the same version numbers for
>> "foo" and "bar" would be a pure coincidence.]
>>
>> In particular, version and package changes are confined to
>> where code changes happen; they follow the development of
>> specific features (while non-impacted code is not forced to
>> adopt a version that is actually related to "foreign" code).
>>
>> Another fundamental advantage, community-wise, is that it is
>> conducive to maintaining a good relationship among developers
>> even if they want to "scratch different itches".[3]
>>
>> In effet, this scheme would allow to group codes by "broad"
>> subject while module management could be fine-grained,[4]
>> up to using specific version suffixes (such as "-dev" or
>> "-extras") to convey intended use or audience or level of
>> support...
>>
>>
>> Regards,
>> Gilles
>>
>> [1] Provided the dependencies are correct of course.
>> [2] According to Stian, it does not (IIRC).
>> [3] Whereas the current scheme turned different POV into personal
>> fights, with punctual winners and losers (however gracefully
>> they think they can handle it) but an enduring overall loss
>> for the community.
>> [4] On a par with the varying levels of development (for whatever
>> reasons, such as lack of time or lack of contributors) of those
>> modules.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 27 Nov 2016 21:19:16 +0000, Benedikt Ritter wrote:
>>[...]
>>
>
> You have asked for opinions - be prepared people don't agree with
> you.
>
>> [...]
>
> Just because it is supported doesn't mean it is a good idea.
>
I actually expected arguments as to why it would not be a good
idea.
You are right that I only got opinions.
Gilles
>>
>> Regards,
>> Gilles
>>
>> >
>> > On 27 November 2016 at 07:36, Rob Tompkins <ch...@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
>> <br...@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"
>> <jo...@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
Re: [ALL] Version number(s) for modular components
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 27 Nov 2016 20:35:51 -0600, Matt Sicker wrote:
> Here's an example of a confusing versioning situation:
>
> 1. commons-foo-base version 1.1 is released
> 2. commons-foo-utils is still at version 1.0 as no code was updated.
> Do you
> release a 1.0.1 with a dependency update on commons-foo-base 1.1,
No.
Case 1:
IF
"commons-foo-utils" can benefit from the newer "commons-foo-base"
AND
the development team has the time to make the necessary updates to
"commons-foo-utils" (i.e. updating it will not unduly delay the
release of "commons-foo-base")
THEN
"commons-foo-utils" 1.1 is released (add 1 to the "minor" version
number, not to the "bug-fix" version number) with a dependency to
"commons-foo-base" 1.1
Case 2:
IF
"commons-foo-utils" does not use any of the new features in
"commons-foo-base" 1.1
THEN
there is no new release of "commons-foo-utils"
Advantage (as noted earlier): a user who only uses "commons-foo-utils"
need not worry about upgrading its dependency (while in the "simple"
scheme, he has to, e.g. before he can report bugs).
> or do you
> go with version 1.1 to match,
There is nothing try and match; cf. my original post:
---QUOTE---
[It should be clear that having the same version numbers for
"foo" and "bar" would be a pure coincidence.]
---QUOTE---
> or do you not even bother updating
> and expect the user to update the version of its transitive
> dependency?
No.
IF
there was no change in the version number of "commons-foo-utils"
THEN
there was no change in the dependencies of "commons-foo-utils"
The development cycles of the modules within a component are
potentially completely independent.[1]
In the same way that the development cycle of "Commons" components
is independent,
In the same way that the development cycle of non-"Commons" projects
is independent.
In the same way that the development cycle of the JDK is independent.
In the same way that the development cycle of the OS is independent.
Etc.
One module can decide to upgrade, or not, depending on the available
resources.
In your example, the release of "commons-foo-utils" 1.1 can happen
months after the release of "commons-foo-base" 1.1.
[It could even be so that a "commons-foo-base" 1.2 was released in
int the mean time, and then "commons-foo-utils" 1.1 would likely
depend on "commons-foo-base" 1.2.]
Regards,
Gilles
[1] Even if, in practice, we'd tend to make as many simultaneous
releases, to minimize the number of [VOTE] posts.
> On 27 November 2016 at 18:12, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
>> [...]
>>>>
>>>
>>> <IMO>
>>> Let's keep in mind the context here: This is a component in Apache
>>> Commons,
>>> not a TLP. Therefore, IMO, we should match user's expectations of
>>> simplicity, which is one repo and version for the component,
>>> multi-module
>>> or not, just like all of the other Apache Commons components, where
>>> all
>>> Commons multi-module components are released as one version.
>>> </IMO>
>>>
>>
>> So, the issue is not to try and decide whether an idea is good or
>> bad,
>> but to follow a rule that is deemed "simple".[1]
>>
>> The problem is that this rule is not one, since I gave a
>> counter-example
>> with "Commons Math".
>>
>> If such "Commons" policies (good or bad) would be documented and
>> _enforced_,[2] much less discussion would ensue.
>> And more people might become aware of the contradictions brought
>> along
>> with the set of rules they qualify as "simple" when a project does
>> not
>> fit their a priori conceptions.
>>
>>
>> Gilles
>>
>> [1] And nothing that has been said is a convincing argument that a
>> single version number, for a bunch of weakly related codes,
>> better
>> qualify as "simple" rather than "misleading".
>> [2] Branch "MATH_3_X" of "Commons Math" would either have been
>> vetoed
>> or the rule which you advocate here (one version per repo) would
>> have been repealed, years ago.
>> It is such contradictions that make it very difficult to go
>> forward
>> in "Commons".
>>
>>
>>> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Matt Sicker <bo...@gmail.com>.
Here's an example of a confusing versioning situation:
1. commons-foo-base version 1.1 is released
2. commons-foo-utils is still at version 1.0 as no code was updated. Do you
release a 1.0.1 with a dependency update on commons-foo-base 1.1, or do you
go with version 1.1 to match, or do you not even bother updating and expect
the user to update the version of its transitive dependency?
On 27 November 2016 at 18:12, Gilles <gi...@harfang.homelinux.org> wrote:
> [...]
>>>
>>
>> <IMO>
>> Let's keep in mind the context here: This is a component in Apache
>> Commons,
>> not a TLP. Therefore, IMO, we should match user's expectations of
>> simplicity, which is one repo and version for the component, multi-module
>> or not, just like all of the other Apache Commons components, where all
>> Commons multi-module components are released as one version.
>> </IMO>
>>
>
> So, the issue is not to try and decide whether an idea is good or bad,
> but to follow a rule that is deemed "simple".[1]
>
> The problem is that this rule is not one, since I gave a counter-example
> with "Commons Math".
>
> If such "Commons" policies (good or bad) would be documented and
> _enforced_,[2] much less discussion would ensue.
> And more people might become aware of the contradictions brought along
> with the set of rules they qualify as "simple" when a project does not
> fit their a priori conceptions.
>
>
> Gilles
>
> [1] And nothing that has been said is a convincing argument that a
> single version number, for a bunch of weakly related codes, better
> qualify as "simple" rather than "misleading".
> [2] Branch "MATH_3_X" of "Commons Math" would either have been vetoed
> or the rule which you advocate here (one version per repo) would
> have been repealed, years ago.
> It is such contradictions that make it very difficult to go forward
> in "Commons".
>
>
>> Gary
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [ALL] Version number(s) for modular components
Posted by Gilles <gi...@harfang.homelinux.org>.
>> [...]
>
> <IMO>
> Let's keep in mind the context here: This is a component in Apache
> Commons,
> not a TLP. Therefore, IMO, we should match user's expectations of
> simplicity, which is one repo and version for the component,
> multi-module
> or not, just like all of the other Apache Commons components, where
> all
> Commons multi-module components are released as one version.
> </IMO>
So, the issue is not to try and decide whether an idea is good or bad,
but to follow a rule that is deemed "simple".[1]
The problem is that this rule is not one, since I gave a
counter-example
with "Commons Math".
If such "Commons" policies (good or bad) would be documented and
_enforced_,[2] much less discussion would ensue.
And more people might become aware of the contradictions brought along
with the set of rules they qualify as "simple" when a project does not
fit their a priori conceptions.
Gilles
[1] And nothing that has been said is a convincing argument that a
single version number, for a bunch of weakly related codes, better
qualify as "simple" rather than "misleading".
[2] Branch "MATH_3_X" of "Commons Math" would either have been vetoed
or the rule which you advocate here (one version per repo) would
have been repealed, years ago.
It is such contradictions that make it very difficult to go forward
in "Commons".
>
> Gary
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Nov 27, 2016 at 1:19 PM, Benedikt Ritter <br...@apache.org> wrote:
> Hello Gilles,
>
> Gilles <gi...@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.
>
<IMO>
Let's keep in mind the context here: This is a component in Apache Commons,
not a TLP. Therefore, IMO, we should match user's expectations of
simplicity, which is one repo and version for the component, multi-module
or not, just like all of the other Apache Commons components, where all
Commons multi-module components are released as one version.
</IMO>
Gary
>
>
> >
> > Regards,
> > Gilles
> >
> > >
> > > On 27 November 2016 at 07:36, Rob Tompkins <ch...@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 <br...@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" <jo...@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
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Version number(s) for modular components
Posted by Benedikt Ritter <br...@apache.org>.
Hello Gilles,
Gilles <gi...@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 <ch...@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 <br...@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" <jo...@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
>
>
Re: [ALL] Version number(s) for modular components
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Nov 28, 2016 at 2:57 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>
>> Gilles,
>>
>> If you try to do this you are going to get very frustrated with
>> Maven. You cannot use the Maven Release plugin if all the versions are
>> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
>> little sense to have them be out of sync. If you don’t use the release
>> plugin then you will have to come up with some custom release
>> mechanism that somehow can only release a portion of your project.
>> This is going to get rather messy as you will constantly be updating
>> the parent pom to increment versions and require that to be released
>> along with the modules you are releasing - which means your other
>> modules really need to be updated to reflect the new parent version.
>>
>> To be honest, I did what you are suggesting at a former employer. We
>> eventually stopped and synchronized the versions of all the modules.
>> It simply wasn’t worth the effort to have all the versions be
>> different and the only real cost was releasing components with new
>> versions that hadn’t changed.
>>
>
> Thanks for the testimony.
> Even if I have no clue how the version string causes a problem,
> I can readily concede that we can be constrained in how to manage
> a project because of the shortcomings of some tool.
>
> Out of curiosity, is there an alternative (to maven?) that would
> not suffer from this limitation?
A different build tool is not going to change the desire most of us have
for one repo = one version.
You can take a look at Gradle but I do not know if that will help here.
Gary
>
>
> Gilles
>
>
>
>> Ralph
>>
>> On Nov 27, 2016, at 2:11 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>>>
>>>
>>> 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
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Version number(s) for modular components
Posted by Stian Soiland-Reyes <st...@apache.org>.
I don't think we have to be super rigid, just have a general principle. If
a case comes up, we can consider deviations then, rather than form fixed
rules from hypothetical scenarios and then be bound by them.
Something like RFC-style SHOULD - a component release may deviate from the
general rule, but then needs to be aware of the consequences and kind of
justify it on a case by case basis.
(Example: we released a new "major" version BCEL 6 but ended up NOT
changing the package/artifact away from bcel5, even if that is Commons
general rule for major releases. This meant many downstream users could
upgrade without breaking their own APIs.)
As for "dual versions" I'm afraid that was a bit of a tangent - if Foo
release 2.0 produced foo-api 2.0 and foo-util 2.0, then in Debian this
would typically be a single source project "commons-foo" that then produces
two jars in each their own Deb.
Now if Foo Util release 2.1 comes out, which don't include foo-api, then
Debian can't use the same build instructions to build a foo-util 2.1 Deb,
as they would then first need to compile foo-api 2.0 from a different
release. (As an open source distro, Debian insists on compiling from source
and don't access Maven Central). That would however also install the old
foo-util 2.0 - but in Debian you can't have two versions of the same
library without renaming to include the version number in the package name.
A possible workaround then is for such a release to also include the old
2.0 foo-api source, the Debian packaging would the only need to deal with
the differentiated version numbers. This would however require some
trickery release-wise or repository-wise (e.g. gitflow model). Trickery and
complexity makes it harder for everyone.
I'm not sure what rational evidence to present as I think this is mainly a
"style" issue. We have heard several anecdotal arguments against
sub-releases as a general principle, but there is no absolute rational case
against it - many Maven users still do it, so it depends on the situation.
We are also "constrained" by ASF policy to make source releases as
archives, Commons' current use of Maven, and a general feeling about what
can be a separate Commons Component.
This can all change over time - I think this discussion is part of that. In
general open source (e.g. on GitHub) I observe a trend towards smaller
projects in smaller git repositories, with faster release cycles, with
fixes going from a pull request to live deployment in less than a day. ASF
have certain infrastructure, policies and practices, Commons modulate with
our own, and each component can tweak those. It's not all fixed in stone,
changes happen when there is community consensus and someone actively
driving change.
So thank you for raising this point, we should not just assume that
whatever we did yesterday should always be the same way!
I do hope we can agree that the general rule for Commons is simplicity,
both for the user and for developers. While an unnecessary module upgrade
is not as "beautiful" as clean semantic version separations per module, it
is, I would argue, simpler to deal with for both consumers, developers and
release managers.
On 1 Dec 2016 9:05 am, "Gilles" <gi...@harfang.homelinux.org> wrote:
> On Wed, 30 Nov 2016 10:23:37 +0000, Stian Soiland-Reyes wrote:
>
>> Yeah, that could be the better way, with a branched off commit for the
>> "shrunk" project with a smaller <modules> list in the parent, then no
>> particular flags are needed to build from the resulting tag or source
>> repo.
>>
>> I initially planned to do so within the Taverna project (before we moved
>> to
>> ASF), as it could mean smaller releases and avoiding updating OSGi
>> coordinates for no-change. It turned out to alienate the rest of the team
>> as then releasing become even more special, particularly if more than one
>> submodule needed updating. After moving to ASF we had to do release
>> artifacts (not just tags and Maven repo) and we abandoned this idea and
>> had
>> to bite the bullet to release all modules every time.
>>
>
> IIUC, it then makes it easier for the RM, not the users (especially
> those who have to upgrade for "no-change").
>
> I've no problem with that; but let's just say it the way it is.
>
> As an example of projects doing the partial, look at the Clerezza project
>> which practices this using alternative release parents and dists; as an
>> outsider I find it a bit difficult to understand what of the project has
>> been released where (or at all), and which versions go together.
>>
>
> I was not considering a way to make it more difficult for users:
> either they don't touch anything, or they upgrade; in the latter
> alternative, a few lines in the release notes tell them what is
> the last version of each module, and by convention, only that
> combination would be "supported".
>
> Commons components are luckily small, so I think it could be done - but
>> only IF NEEDED, rather than as general practice.
>>
>
> In what cases would you consider it is needed?
> In what cases is it allowed?
> In what cases is it forbidden?
>
> The discussion triggered by the proposal was meant define
> clear rules, with some justification for them in order to curb
> speculation.
>
> But the replies did not clearly demonstrate how the proposal was
> bad.
>
> In this particular case, I'd have nothing against an argument of
> authority, but is should be stated as such.
> Obviously, there are limits to consensus-based policy, unless
> consensus means that people don't care about the rationale of
> their choices.
> In that case, it would be more effective to just have a majority
> vote to which anyone can then refer, rather than having endless
> discussions; some saying it's OK, sometimes, and others saying
> they are against, always.
>
> There is also the consideration of operation system distributions like
>> Debian who prefer a single source archive or tag for the whole project
>> (and
>> no dual versions) - varying this per release means they are going to not
>> update correctly. Several commons component (including math3) are already
>> in Debian.
>>
>
> It could be a rationale for restricting what is possible.
>
> But I don't really understand "dual versions".
> In the proposal, the project's version would always be unique;
> it is supplemented with a version specific to each of its
> modules (i.e. a version is attached to a module/artefact); one
> of these modules could be, by definition, the "distribution"
> (as I've noticed several projects do), whose version would be
> incremented in the same way as is done now for the "project".
>
> This would indeed be just an additional convention!
> And if it's the same for all "Commons" project, the better:
> common build instructions can be published and common tools
> defined in the parent project.[1]
>
> Regards,
> Gilles
>
> [1] Cf. my questions for creating aggregate (i.e. "distribution")
> artefacts for the release of "Commons RNG"; from the answers
> I got, I still could not generate all the required files!
>
>
>> On 30 Nov 2016 9:04 am, "Gilles" <gi...@harfang.homelinux.org> wrote:
>>
>> On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
>>>
>>> What if a feature was added to the maven-release-plugin to release a
>>>> subset
>>>> of submodules? I wonder how feasible that would be.
>>>>
>>>>
>>> When I thought of independent module releases, I assumed that
>>> it would just be a matter of excluding some of the "<module>"
>>> sections in the (parent) POM. [That seemed to work for making
>>> the Jenkins build pass on Java 6 while the "commons-rng-examples"
>>> requires Java 7.]
>>>
>>> Gilles
>>>
>>> On 28 November 2016 at 19:00, Jörg Schaible <jo...@gmx.de>
>>> wrote:
>>>
>>>>
>>>> Gilles wrote:
>>>>
>>>>>
>>>>> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>>>>> >> Gilles,
>>>>> >>
>>>>> >> If you try to do this you are going to get very frustrated with
>>>>> >> Maven. You cannot use the Maven Release plugin if all the versions
>>>>> >> are
>>>>> >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
>>>>> >> little sense to have them be out of sync. If you don’t use the
>>>>> >> release
>>>>> >> plugin then you will have to come up with some custom release
>>>>> >> mechanism that somehow can only release a portion of your project.
>>>>> >> This is going to get rather messy as you will constantly be updating
>>>>> >> the parent pom to increment versions and require that to be released
>>>>> >> along with the modules you are releasing - which means your other
>>>>> >> modules really need to be updated to reflect the new parent version.
>>>>> >>
>>>>> >> To be honest, I did what you are suggesting at a former employer. We
>>>>> >> eventually stopped and synchronized the versions of all the modules.
>>>>> >> It simply wasn’t worth the effort to have all the versions be
>>>>> >> different and the only real cost was releasing components with new
>>>>> >> versions that hadn’t changed.
>>>>> >
>>>>> > Thanks for the testimony.
>>>>> > Even if I have no clue how the version string causes a problem,
>>>>> > I can readily concede that we can be constrained in how to manage
>>>>> > a project because of the shortcomings of some tool.
>>>>>
>>>>> There is no no short coming, you can do otherwise, but if you follow
>>>>> conventions Maven makes your life easy (Maven is all about
>>>>> conventions).
>>>>> However, the release process described in rng does not use the release
>>>>> plugin, so the point is moot.
>>>>>
>>>>> > Out of curiosity, is there an alternative (to maven?) that would
>>>>> > not suffer from this limitation?
>>>>>
>>>>> It's not the tool we're discussing.
>>>>>
>>>>> Cheers,
>>>>> Jörg
>>>>>
>>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [ALL] Version number(s) for modular components
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 30 Nov 2016 10:23:37 +0000, Stian Soiland-Reyes wrote:
> Yeah, that could be the better way, with a branched off commit for
> the
> "shrunk" project with a smaller <modules> list in the parent, then no
> particular flags are needed to build from the resulting tag or source
> repo.
>
> I initially planned to do so within the Taverna project (before we
> moved to
> ASF), as it could mean smaller releases and avoiding updating OSGi
> coordinates for no-change. It turned out to alienate the rest of the
> team
> as then releasing become even more special, particularly if more than
> one
> submodule needed updating. After moving to ASF we had to do release
> artifacts (not just tags and Maven repo) and we abandoned this idea
> and had
> to bite the bullet to release all modules every time.
IIUC, it then makes it easier for the RM, not the users (especially
those who have to upgrade for "no-change").
I've no problem with that; but let's just say it the way it is.
> As an example of projects doing the partial, look at the Clerezza
> project
> which practices this using alternative release parents and dists; as
> an
> outsider I find it a bit difficult to understand what of the project
> has
> been released where (or at all), and which versions go together.
I was not considering a way to make it more difficult for users:
either they don't touch anything, or they upgrade; in the latter
alternative, a few lines in the release notes tell them what is
the last version of each module, and by convention, only that
combination would be "supported".
> Commons components are luckily small, so I think it could be done -
> but
> only IF NEEDED, rather than as general practice.
In what cases would you consider it is needed?
In what cases is it allowed?
In what cases is it forbidden?
The discussion triggered by the proposal was meant define
clear rules, with some justification for them in order to curb
speculation.
But the replies did not clearly demonstrate how the proposal was
bad.
In this particular case, I'd have nothing against an argument of
authority, but is should be stated as such.
Obviously, there are limits to consensus-based policy, unless
consensus means that people don't care about the rationale of
their choices.
In that case, it would be more effective to just have a majority
vote to which anyone can then refer, rather than having endless
discussions; some saying it's OK, sometimes, and others saying
they are against, always.
> There is also the consideration of operation system distributions
> like
> Debian who prefer a single source archive or tag for the whole
> project (and
> no dual versions) - varying this per release means they are going to
> not
> update correctly. Several commons component (including math3) are
> already
> in Debian.
It could be a rationale for restricting what is possible.
But I don't really understand "dual versions".
In the proposal, the project's version would always be unique;
it is supplemented with a version specific to each of its
modules (i.e. a version is attached to a module/artefact); one
of these modules could be, by definition, the "distribution"
(as I've noticed several projects do), whose version would be
incremented in the same way as is done now for the "project".
This would indeed be just an additional convention!
And if it's the same for all "Commons" project, the better:
common build instructions can be published and common tools
defined in the parent project.[1]
Regards,
Gilles
[1] Cf. my questions for creating aggregate (i.e. "distribution")
artefacts for the release of "Commons RNG"; from the answers
I got, I still could not generate all the required files!
>
> On 30 Nov 2016 9:04 am, "Gilles" <gi...@harfang.homelinux.org>
> wrote:
>
>> On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
>>
>>> What if a feature was added to the maven-release-plugin to release
>>> a
>>> subset
>>> of submodules? I wonder how feasible that would be.
>>>
>>
>> When I thought of independent module releases, I assumed that
>> it would just be a matter of excluding some of the "<module>"
>> sections in the (parent) POM. [That seemed to work for making
>> the Jenkins build pass on Java 6 while the "commons-rng-examples"
>> requires Java 7.]
>>
>> Gilles
>>
>> On 28 November 2016 at 19:00, J�rg Schaible <jo...@gmx.de>
>> wrote:
>>>
>>> Gilles wrote:
>>>>
>>>> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>>>> >> Gilles,
>>>> >>
>>>> >> If you try to do this you are going to get very frustrated with
>>>> >> Maven. You cannot use the Maven Release plugin if all the
>>>> versions
>>>> >> are
>>>> >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes
>>>> very
>>>> >> little sense to have them be out of sync. If you don\u2019t use the
>>>> >> release
>>>> >> plugin then you will have to come up with some custom release
>>>> >> mechanism that somehow can only release a portion of your
>>>> project.
>>>> >> This is going to get rather messy as you will constantly be
>>>> updating
>>>> >> the parent pom to increment versions and require that to be
>>>> released
>>>> >> along with the modules you are releasing - which means your
>>>> other
>>>> >> modules really need to be updated to reflect the new parent
>>>> version.
>>>> >>
>>>> >> To be honest, I did what you are suggesting at a former
>>>> employer. We
>>>> >> eventually stopped and synchronized the versions of all the
>>>> modules.
>>>> >> It simply wasn\u2019t worth the effort to have all the versions be
>>>> >> different and the only real cost was releasing components with
>>>> new
>>>> >> versions that hadn\u2019t changed.
>>>> >
>>>> > Thanks for the testimony.
>>>> > Even if I have no clue how the version string causes a problem,
>>>> > I can readily concede that we can be constrained in how to
>>>> manage
>>>> > a project because of the shortcomings of some tool.
>>>>
>>>> There is no no short coming, you can do otherwise, but if you
>>>> follow
>>>> conventions Maven makes your life easy (Maven is all about
>>>> conventions).
>>>> However, the release process described in rng does not use the
>>>> release
>>>> plugin, so the point is moot.
>>>>
>>>> > Out of curiosity, is there an alternative (to maven?) that would
>>>> > not suffer from this limitation?
>>>>
>>>> It's not the tool we're discussing.
>>>>
>>>> Cheers,
>>>> J�rg
>>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Stian Soiland-Reyes <st...@apache.org>.
Yeah, that could be the better way, with a branched off commit for the
"shrunk" project with a smaller <modules> list in the parent, then no
particular flags are needed to build from the resulting tag or source repo.
I initially planned to do so within the Taverna project (before we moved to
ASF), as it could mean smaller releases and avoiding updating OSGi
coordinates for no-change. It turned out to alienate the rest of the team
as then releasing become even more special, particularly if more than one
submodule needed updating. After moving to ASF we had to do release
artifacts (not just tags and Maven repo) and we abandoned this idea and had
to bite the bullet to release all modules every time.
As an example of projects doing the partial, look at the Clerezza project
which practices this using alternative release parents and dists; as an
outsider I find it a bit difficult to understand what of the project has
been released where (or at all), and which versions go together.
Commons components are luckily small, so I think it could be done - but
only IF NEEDED, rather than as general practice.
There is also the consideration of operation system distributions like
Debian who prefer a single source archive or tag for the whole project (and
no dual versions) - varying this per release means they are going to not
update correctly. Several commons component (including math3) are already
in Debian.
On 30 Nov 2016 9:04 am, "Gilles" <gi...@harfang.homelinux.org> wrote:
> On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
>
>> What if a feature was added to the maven-release-plugin to release a
>> subset
>> of submodules? I wonder how feasible that would be.
>>
>
> When I thought of independent module releases, I assumed that
> it would just be a matter of excluding some of the "<module>"
> sections in the (parent) POM. [That seemed to work for making
> the Jenkins build pass on Java 6 while the "commons-rng-examples"
> requires Java 7.]
>
> Gilles
>
> On 28 November 2016 at 19:00, Jörg Schaible <jo...@gmx.de> wrote:
>>
>> Gilles wrote:
>>>
>>> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>>> >> Gilles,
>>> >>
>>> >> If you try to do this you are going to get very frustrated with
>>> >> Maven. You cannot use the Maven Release plugin if all the versions
>>> >> are
>>> >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
>>> >> little sense to have them be out of sync. If you don’t use the
>>> >> release
>>> >> plugin then you will have to come up with some custom release
>>> >> mechanism that somehow can only release a portion of your project.
>>> >> This is going to get rather messy as you will constantly be updating
>>> >> the parent pom to increment versions and require that to be released
>>> >> along with the modules you are releasing - which means your other
>>> >> modules really need to be updated to reflect the new parent version.
>>> >>
>>> >> To be honest, I did what you are suggesting at a former employer. We
>>> >> eventually stopped and synchronized the versions of all the modules.
>>> >> It simply wasn’t worth the effort to have all the versions be
>>> >> different and the only real cost was releasing components with new
>>> >> versions that hadn’t changed.
>>> >
>>> > Thanks for the testimony.
>>> > Even if I have no clue how the version string causes a problem,
>>> > I can readily concede that we can be constrained in how to manage
>>> > a project because of the shortcomings of some tool.
>>>
>>> There is no no short coming, you can do otherwise, but if you follow
>>> conventions Maven makes your life easy (Maven is all about conventions).
>>> However, the release process described in rng does not use the release
>>> plugin, so the point is moot.
>>>
>>> > Out of curiosity, is there an alternative (to maven?) that would
>>> > not suffer from this limitation?
>>>
>>> It's not the tool we're discussing.
>>>
>>> Cheers,
>>> Jörg
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [ALL] Version number(s) for modular components
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 29 Nov 2016 21:56:34 -0600, Matt Sicker wrote:
> What if a feature was added to the maven-release-plugin to release a
> subset
> of submodules? I wonder how feasible that would be.
When I thought of independent module releases, I assumed that
it would just be a matter of excluding some of the "<module>"
sections in the (parent) POM. [That seemed to work for making
the Jenkins build pass on Java 6 while the "commons-rng-examples"
requires Java 7.]
Gilles
> On 28 November 2016 at 19:00, J�rg Schaible <jo...@gmx.de>
> wrote:
>
>> Gilles wrote:
>>
>> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>> >> Gilles,
>> >>
>> >> If you try to do this you are going to get very frustrated with
>> >> Maven. You cannot use the Maven Release plugin if all the
>> versions
>> >> are
>> >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes
>> very
>> >> little sense to have them be out of sync. If you don\u2019t use the
>> >> release
>> >> plugin then you will have to come up with some custom release
>> >> mechanism that somehow can only release a portion of your
>> project.
>> >> This is going to get rather messy as you will constantly be
>> updating
>> >> the parent pom to increment versions and require that to be
>> released
>> >> along with the modules you are releasing - which means your other
>> >> modules really need to be updated to reflect the new parent
>> version.
>> >>
>> >> To be honest, I did what you are suggesting at a former employer.
>> We
>> >> eventually stopped and synchronized the versions of all the
>> modules.
>> >> It simply wasn\u2019t worth the effort to have all the versions be
>> >> different and the only real cost was releasing components with
>> new
>> >> versions that hadn\u2019t changed.
>> >
>> > Thanks for the testimony.
>> > Even if I have no clue how the version string causes a problem,
>> > I can readily concede that we can be constrained in how to manage
>> > a project because of the shortcomings of some tool.
>>
>> There is no no short coming, you can do otherwise, but if you follow
>> conventions Maven makes your life easy (Maven is all about
>> conventions).
>> However, the release process described in rng does not use the
>> release
>> plugin, so the point is moot.
>>
>> > Out of curiosity, is there an alternative (to maven?) that would
>> > not suffer from this limitation?
>>
>> It's not the tool we're discussing.
>>
>> Cheers,
>> J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Matt Sicker <bo...@gmail.com>.
What if a feature was added to the maven-release-plugin to release a subset
of submodules? I wonder how feasible that would be.
On 28 November 2016 at 19:00, Jörg Schaible <jo...@gmx.de> wrote:
> Gilles wrote:
>
> > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
> >> Gilles,
> >>
> >> If you try to do this you are going to get very frustrated with
> >> Maven. You cannot use the Maven Release plugin if all the versions
> >> are
> >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
> >> little sense to have them be out of sync. If you don’t use the
> >> release
> >> plugin then you will have to come up with some custom release
> >> mechanism that somehow can only release a portion of your project.
> >> This is going to get rather messy as you will constantly be updating
> >> the parent pom to increment versions and require that to be released
> >> along with the modules you are releasing - which means your other
> >> modules really need to be updated to reflect the new parent version.
> >>
> >> To be honest, I did what you are suggesting at a former employer. We
> >> eventually stopped and synchronized the versions of all the modules.
> >> It simply wasn’t worth the effort to have all the versions be
> >> different and the only real cost was releasing components with new
> >> versions that hadn’t changed.
> >
> > Thanks for the testimony.
> > Even if I have no clue how the version string causes a problem,
> > I can readily concede that we can be constrained in how to manage
> > a project because of the shortcomings of some tool.
>
> There is no no short coming, you can do otherwise, but if you follow
> conventions Maven makes your life easy (Maven is all about conventions).
> However, the release process described in rng does not use the release
> plugin, so the point is moot.
>
> > Out of curiosity, is there an alternative (to maven?) that would
> > not suffer from this limitation?
>
> It's not the tool we're discussing.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [ALL] Version number(s) for modular components
Posted by Jörg Schaible <jo...@gmx.de>.
Gilles wrote:
> On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
>> Gilles,
>>
>> If you try to do this you are going to get very frustrated with
>> Maven. You cannot use the Maven Release plugin if all the versions
>> are
>> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
>> little sense to have them be out of sync. If you don\u2019t use the
>> release
>> plugin then you will have to come up with some custom release
>> mechanism that somehow can only release a portion of your project.
>> This is going to get rather messy as you will constantly be updating
>> the parent pom to increment versions and require that to be released
>> along with the modules you are releasing - which means your other
>> modules really need to be updated to reflect the new parent version.
>>
>> To be honest, I did what you are suggesting at a former employer. We
>> eventually stopped and synchronized the versions of all the modules.
>> It simply wasn\u2019t worth the effort to have all the versions be
>> different and the only real cost was releasing components with new
>> versions that hadn\u2019t changed.
>
> Thanks for the testimony.
> Even if I have no clue how the version string causes a problem,
> I can readily concede that we can be constrained in how to manage
> a project because of the shortcomings of some tool.
There is no no short coming, you can do otherwise, but if you follow
conventions Maven makes your life easy (Maven is all about conventions).
However, the release process described in rng does not use the release
plugin, so the point is moot.
> Out of curiosity, is there an alternative (to maven?) that would
> not suffer from this limitation?
It's not the tool we're discussing.
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote:
> Gilles,
>
> If you try to do this you are going to get very frustrated with
> Maven. You cannot use the Maven Release plugin if all the versions
> are
> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very
> little sense to have them be out of sync. If you don\u2019t use the
> release
> plugin then you will have to come up with some custom release
> mechanism that somehow can only release a portion of your project.
> This is going to get rather messy as you will constantly be updating
> the parent pom to increment versions and require that to be released
> along with the modules you are releasing - which means your other
> modules really need to be updated to reflect the new parent version.
>
> To be honest, I did what you are suggesting at a former employer. We
> eventually stopped and synchronized the versions of all the modules.
> It simply wasn\u2019t worth the effort to have all the versions be
> different and the only real cost was releasing components with new
> versions that hadn\u2019t changed.
Thanks for the testimony.
Even if I have no clue how the version string causes a problem,
I can readily concede that we can be constrained in how to manage
a project because of the shortcomings of some tool.
Out of curiosity, is there an alternative (to maven?) that would
not suffer from this limitation?
Gilles
>
> Ralph
>
>> On Nov 27, 2016, at 2:11 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>>
>> 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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Apache <ra...@dslextreme.com>.
Gilles,
If you try to do this you are going to get very frustrated with Maven. You cannot use the Maven Release plugin if all the versions are not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very little sense to have them be out of sync. If you don’t use the release plugin then you will have to come up with some custom release mechanism that somehow can only release a portion of your project. This is going to get rather messy as you will constantly be updating the parent pom to increment versions and require that to be released along with the modules you are releasing - which means your other modules really need to be updated to reflect the new parent version.
To be honest, I did what you are suggesting at a former employer. We eventually stopped and synchronized the versions of all the modules. It simply wasn’t worth the effort to have all the versions be different and the only real cost was releasing components with new versions that hadn’t changed.
Ralph
> On Nov 27, 2016, at 2:11 PM, Gilles <gi...@harfang.homelinux.org> wrote:
>
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <ch...@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 <br...@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" <jo...@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
Re: [ALL] Version number(s) for modular components
Posted by Matt Sicker <bo...@gmail.com>.
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.
On 27 November 2016 at 07:36, Rob Tompkins <ch...@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 <br...@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" <jo...@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
> >>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [ALL] Version number(s) for modular components
Posted by Rob Tompkins <ch...@gmail.com>.
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 <br...@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" <jo...@gmx.de> wrote:
>>>
>>> Gary Gregory wrote:
>>>
>>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <jo...@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
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Version number(s) for modular components
Posted by Benedikt Ritter <br...@apache.org>.
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" <jo...@gmx.de> wrote:
>
> > Gary Gregory wrote:
> >
> > > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <jo...@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
> >
> >
>
Re: [ALL] Version number(s) for modular components
Posted by Stian Soiland-Reyes <st...@apache.org>.
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" <jo...@gmx.de> wrote:
> Gary Gregory wrote:
>
> > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <jo...@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
>
>
Re: [ALL] Version number(s) for modular components
Posted by Jörg Schaible <jo...@gmx.de>.
Gary Gregory wrote:
> On Sat, Nov 26, 2016 at 9:06 AM, J�rg Schaible <jo...@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
Re: [ALL] Version number(s) for modular components
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <jo...@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.
Gary
>
> - Jörg
>
> Gilles wrote:
>
> > Hello.
> >
> > As a follow-up of
> > http://markmail.org/message/jckbknphndecglns
> > and
> > http://markmail.org/message/f3g33kvevf52xohf
> > I summarize what I think should be allowed for versioning
> > modularized components of the "Commons" project.
> >
> > Assume there are two modules in project "Commons ModProj":
> > commons-modproj-foo
> > commons-modproj-bar
> >
> > Their respective "top-level package" would be:
> > org.apache.commons.modproj.foo
> > org.apache.commons.modproj.bar
> >
> > I propose that versioning of the modules are independent
> > (as if they were different components).
> >
> > As said in the referred posts, it would allow the version
> > numbers to reflect the actual state of each of the module.
> > For example, assume that this proposal is validated, and
> > that
> > commons-modproj-foo-1.0
> > commons-modproj-bar-1.1
> > were released.
> >
> > Note: for the sake of exercising the version changes, all the
> > cases below happen in the sequence shown (ala "switch" with
> > "case" without "break").
> >
> > === Case (A) ===
> >
> > We must release a non-BC upgrade of "bar".
> > Hence, we would release
> > commons-modproj-bar-2.0
> > with "top-level package"
> > org.apache.commons.modproj.bar2
> >
> > Advantage: applications that only use module "foo" are unaffected.
> >
> > === Case (B) ===
> >
> > Assume that "bar" depends on "foo".
> >
> > -- Case (B1) --
> > We release a BC version of "foo":
> > commons-modproj-foo-1.1
> >
> > * Case (B1+)
> > The upgrade consists of new features only.
> > Module "bar" is totally unaffected (what worked with foo-1.0
> > works the same with foo-1.1) and no new release of "bar2"
> > will happen.
> >
> > Advantage: users of "bar2" only will not wonder whether they
> > should upgrade (if they did not intend to use new features,
> > there is no reason for them to upgrade).
> >
> > * Case (B1-)
> > The upgrade consists of bug fixes.
> > Both modules will be released, i.e.
> > commons-modproj-foo-1.1.1
> > commons-modproj-bar2-2.0.1
> >
> > This will trigger an upgrade for all users (who care about
> > correctness).
> >
> > -- Case (B2) --
> > We release a non-BC version of "foo":
> > commons-modproj-foo2-2.0
> > with "top-level package"
> > org.apache.commons.modproj.foo2
> >
> > * Case (B2+)
> > The upgrade is purely a re-design.
> >
> > The development team is free to (major) release the new
> > "foo2-2.0" without having upgraded "bar2", i.e. latest "bar2"
> > (2.0.1) still uses "foo-1.1.1".
> >
> > ~ Case (B2+sync)
> > Team is able to provide, at time of release, a bridge and
> > release
> > commons-modproj-bar2-2.1
> > so that users of "bar2-2.1" will transparently use
> > "foo2-2.0"
> > (in place of "foo-1.1.1").
> >
> > ~ Case (B2+async)
> > Team is able to provide (or improve) the bridge later on,
> > i.e. release
> > commons-modproj-foo2-2.1
> > commons-modproj-bar2-2.2
> > so that users of "bar2" only will transparently use
> > "foo2-2.1"
> > (in place of "foo-1.1.1" or "foo2-2.0").
> >
> > Advantages:
> > - Redesigned "foo" can be released without worrying about
> > upgrading "bar" (RERO).
> > - Users of "bar2" only can either not worry about upgrade,
> > or just update their version dependency (not changing a
> > single line of code).
> >
> > * Case (B2++)
> > Previous re-design turned out to be sub-optimal.
> >
> > A new major "foo" is released:
> > commons-modproj-foo3-3.0
> > with "top-level package"
> > org.apache.commons.modproj.foo3
> >
> > [Same (non-)consequences for "bar2" as previous case.]
> >
> > * Case (B2-)
> > An upgrade also contains bug-fixes.
> >
> > A new major "foo" will be released, i.e.
> > commons-modproj-foo4-4.0
> > with "top-level package"
> > org.apache.commons.modproj.foo4
> > together with a new major "bar"
> > commons-modproj-bar3-3.0
> > with "top-level package"
> > org.apache.commons.modproj.bar3
> >
> > Here the upgrade of "bar" will force its users to think
> > about whether they need to upgrade (whether they are
> > impacted by the bugs or they want to have support usually
> > provided for latest version only).
> >
> > === Case (C) ===
> >
> > People want to completely redesign the whole "ModProj" functionality.
> >
> > We can release
> > commons-modproj2-foo-1.0
> > commons-modproj2-bar-1.0
> >
> > Their respective "top-level package" would be:
> > org.apache.commons.modproj2.foo
> > org.apache.commons.modproj2.bar
> >
> >
> > At this point we'd have these modules officially released:
> > commons-modproj-foo4-4.0
> > commons-modproj-bar3-3.0
> > commons-modproj2-foo-1.0
> > commons-modproj2-bar-1.0
> > all happily living together[1]; and improvements can be easily
> > exchanged among the different lines of development (e.g. via
> > "git" branches).
> >
> > Obviously, the significant change is that version numbers are
> > tied to modules, not component. Does that pose a problem?[2]
> > [It should be clear that having the same version numbers for
> > "foo" and "bar" would be a pure coincidence.]
> >
> > In particular, version and package changes are confined to
> > where code changes happen; they follow the development of
> > specific features (while non-impacted code is not forced to
> > adopt a version that is actually related to "foreign" code).
> >
> > Another fundamental advantage, community-wise, is that it is
> > conducive to maintaining a good relationship among developers
> > even if they want to "scratch different itches".[3]
> >
> > In effet, this scheme would allow to group codes by "broad"
> > subject while module management could be fine-grained,[4]
> > up to using specific version suffixes (such as "-dev" or
> > "-extras") to convey intended use or audience or level of
> > support...
> >
> >
> > Regards,
> > Gilles
> >
> > [1] Provided the dependencies are correct of course.
> > [2] According to Stian, it does not (IIRC).
> > [3] Whereas the current scheme turned different POV into personal
> > fights, with punctual winners and losers (however gracefully
> > they think they can handle it) but an enduring overall loss
> > for the community.
> > [4] On a par with the varying levels of development (for whatever
> > reasons, such as lack of time or lack of contributors) of those
> > modules.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Version number(s) for modular components
Posted by Jörg Schaible <jo...@gmx.de>.
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.
I still propose commons-rng-tools as separate component. Because of this
mail. KISS.
- J�rg
Gilles wrote:
> Hello.
>
> As a follow-up of
> http://markmail.org/message/jckbknphndecglns
> and
> http://markmail.org/message/f3g33kvevf52xohf
> I summarize what I think should be allowed for versioning
> modularized components of the "Commons" project.
>
> Assume there are two modules in project "Commons ModProj":
> commons-modproj-foo
> commons-modproj-bar
>
> Their respective "top-level package" would be:
> org.apache.commons.modproj.foo
> org.apache.commons.modproj.bar
>
> I propose that versioning of the modules are independent
> (as if they were different components).
>
> As said in the referred posts, it would allow the version
> numbers to reflect the actual state of each of the module.
> For example, assume that this proposal is validated, and
> that
> commons-modproj-foo-1.0
> commons-modproj-bar-1.1
> were released.
>
> Note: for the sake of exercising the version changes, all the
> cases below happen in the sequence shown (ala "switch" with
> "case" without "break").
>
> === Case (A) ===
>
> We must release a non-BC upgrade of "bar".
> Hence, we would release
> commons-modproj-bar-2.0
> with "top-level package"
> org.apache.commons.modproj.bar2
>
> Advantage: applications that only use module "foo" are unaffected.
>
> === Case (B) ===
>
> Assume that "bar" depends on "foo".
>
> -- Case (B1) --
> We release a BC version of "foo":
> commons-modproj-foo-1.1
>
> * Case (B1+)
> The upgrade consists of new features only.
> Module "bar" is totally unaffected (what worked with foo-1.0
> works the same with foo-1.1) and no new release of "bar2"
> will happen.
>
> Advantage: users of "bar2" only will not wonder whether they
> should upgrade (if they did not intend to use new features,
> there is no reason for them to upgrade).
>
> * Case (B1-)
> The upgrade consists of bug fixes.
> Both modules will be released, i.e.
> commons-modproj-foo-1.1.1
> commons-modproj-bar2-2.0.1
>
> This will trigger an upgrade for all users (who care about
> correctness).
>
> -- Case (B2) --
> We release a non-BC version of "foo":
> commons-modproj-foo2-2.0
> with "top-level package"
> org.apache.commons.modproj.foo2
>
> * Case (B2+)
> The upgrade is purely a re-design.
>
> The development team is free to (major) release the new
> "foo2-2.0" without having upgraded "bar2", i.e. latest "bar2"
> (2.0.1) still uses "foo-1.1.1".
>
> ~ Case (B2+sync)
> Team is able to provide, at time of release, a bridge and
> release
> commons-modproj-bar2-2.1
> so that users of "bar2-2.1" will transparently use
> "foo2-2.0"
> (in place of "foo-1.1.1").
>
> ~ Case (B2+async)
> Team is able to provide (or improve) the bridge later on,
> i.e. release
> commons-modproj-foo2-2.1
> commons-modproj-bar2-2.2
> so that users of "bar2" only will transparently use
> "foo2-2.1"
> (in place of "foo-1.1.1" or "foo2-2.0").
>
> Advantages:
> - Redesigned "foo" can be released without worrying about
> upgrading "bar" (RERO).
> - Users of "bar2" only can either not worry about upgrade,
> or just update their version dependency (not changing a
> single line of code).
>
> * Case (B2++)
> Previous re-design turned out to be sub-optimal.
>
> A new major "foo" is released:
> commons-modproj-foo3-3.0
> with "top-level package"
> org.apache.commons.modproj.foo3
>
> [Same (non-)consequences for "bar2" as previous case.]
>
> * Case (B2-)
> An upgrade also contains bug-fixes.
>
> A new major "foo" will be released, i.e.
> commons-modproj-foo4-4.0
> with "top-level package"
> org.apache.commons.modproj.foo4
> together with a new major "bar"
> commons-modproj-bar3-3.0
> with "top-level package"
> org.apache.commons.modproj.bar3
>
> Here the upgrade of "bar" will force its users to think
> about whether they need to upgrade (whether they are
> impacted by the bugs or they want to have support usually
> provided for latest version only).
>
> === Case (C) ===
>
> People want to completely redesign the whole "ModProj" functionality.
>
> We can release
> commons-modproj2-foo-1.0
> commons-modproj2-bar-1.0
>
> Their respective "top-level package" would be:
> org.apache.commons.modproj2.foo
> org.apache.commons.modproj2.bar
>
>
> At this point we'd have these modules officially released:
> commons-modproj-foo4-4.0
> commons-modproj-bar3-3.0
> commons-modproj2-foo-1.0
> commons-modproj2-bar-1.0
> all happily living together[1]; and improvements can be easily
> exchanged among the different lines of development (e.g. via
> "git" branches).
>
> Obviously, the significant change is that version numbers are
> tied to modules, not component. Does that pose a problem?[2]
> [It should be clear that having the same version numbers for
> "foo" and "bar" would be a pure coincidence.]
>
> In particular, version and package changes are confined to
> where code changes happen; they follow the development of
> specific features (while non-impacted code is not forced to
> adopt a version that is actually related to "foreign" code).
>
> Another fundamental advantage, community-wise, is that it is
> conducive to maintaining a good relationship among developers
> even if they want to "scratch different itches".[3]
>
> In effet, this scheme would allow to group codes by "broad"
> subject while module management could be fine-grained,[4]
> up to using specific version suffixes (such as "-dev" or
> "-extras") to convey intended use or audience or level of
> support...
>
>
> Regards,
> Gilles
>
> [1] Provided the dependencies are correct of course.
> [2] According to Stian, it does not (IIRC).
> [3] Whereas the current scheme turned different POV into personal
> fights, with punctual winners and losers (however gracefully
> they think they can handle it) but an enduring overall loss
> for the community.
> [4] On a par with the varying levels of development (for whatever
> reasons, such as lack of time or lack of contributors) of those
> modules.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org