[ALL] Version number(s) for modular components

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ALL] Version number(s) for modular components

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Jörg Schaible
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Rob Tompkins
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

garydgregory
In reply to this post by Jörg Schaible
On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

garydgregory
In reply to this post by Rob Tompkins
On Sat, Nov 26, 2016 at 9:28 AM, Rob Tompkins <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Charles Honton
In reply to this post by Rob Tompkins
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Jörg Schaible
In reply to this post by garydgregory
Gary Gregory wrote:

> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Stian Soiland-Reyes
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" <[hidden email]> wrote:

> Gary Gregory wrote:
>
> > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <[hidden email]>
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Benedikt Ritter-4
I'm also in the "one-version per repository"-camp.

Benedikt

Stian Soiland-Reyes <[hidden email]> 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" <[hidden email]> wrote:
>
> > Gary Gregory wrote:
> >
> > > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <[hidden email]>
> > > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Rob Tompkins
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 <[hidden email]> wrote:
>
> I'm also in the "one-version per repository"-camp.
>
> Benedikt
>
> Stian Soiland-Reyes <[hidden email]> 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" <[hidden email]> wrote:
>>>
>>> Gary Gregory wrote:
>>>
>>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <[hidden email]>
>>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Matt Sicker
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 <[hidden email]> 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 <[hidden email]> wrote:
> >
> > I'm also in the "one-version per repository"-camp.
> >
> > Benedikt
> >
> > Stian Soiland-Reyes <[hidden email]> 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" <[hidden email]>
> wrote:
> >>>
> >>> Gary Gregory wrote:
> >>>
> >>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <[hidden email]
> >
> >>>> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Gilles Sadowski
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 <[hidden email]>
> 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 <[hidden email]>
>> wrote:
>> >
>> > I'm also in the "one-version per repository"-camp.
>> >
>> > Benedikt
>> >
>> > Stian Soiland-Reyes <[hidden email]> 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" <[hidden email]>
>> wrote:
>> >>>
>> >>> Gary Gregory wrote:
>> >>>
>> >>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible
>> <[hidden email]
>> >
>> >>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Benedikt Ritter-4
Hello Gilles,

Gilles <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> >> wrote:
> >> >
> >> > I'm also in the "one-version per repository"-camp.
> >> >
> >> > Benedikt
> >> >
> >> > Stian Soiland-Reyes <[hidden email]> 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" <[hidden email]>
> >> wrote:
> >> >>>
> >> >>> Gary Gregory wrote:
> >> >>>
> >> >>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible
> >> <[hidden email]
> >> >
> >> >>>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

garydgregory
On Sun, Nov 27, 2016 at 1:19 PM, Benedikt Ritter <[hidden email]> wrote:

> Hello Gilles,
>
> Gilles <[hidden email]> 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 <[hidden email]>
> > > 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 <[hidden email]>
> > >> wrote:
> > >> >
> > >> > I'm also in the "one-version per repository"-camp.
> > >> >
> > >> > Benedikt
> > >> >
> > >> > Stian Soiland-Reyes <[hidden email]> 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" <[hidden email]>
> > >> wrote:
> > >> >>>
> > >> >>> Gary Gregory wrote:
> > >> >>>
> > >> >>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible
> > >> <[hidden email]
> > >> >
> > >> >>>> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Gilles Sadowski
In reply to this post by Benedikt Ritter-4
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 <[hidden email]>
>> > 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
>> <[hidden email]>
>> >> wrote:
>> >> >
>> >> > I'm also in the "one-version per repository"-camp.
>> >> >
>> >> > Benedikt
>> >> >
>> >> > Stian Soiland-Reyes <[hidden email]> 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"
>> <[hidden email]>
>> >> wrote:
>> >> >>>
>> >> >>> Gary Gregory wrote:
>> >> >>>
>> >> >>>> On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible
>> >> <[hidden email]
>> >> >
>> >> >>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Gilles Sadowski
In reply to this post by garydgregory
>> [...]
>
> <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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Matt Sicker
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Gilles Sadowski
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 <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Ralph Goers
In reply to this post by Gilles Sadowski
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] Version number(s) for modular components

Gilles Sadowski
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?

Gilles

>
> Ralph
>
>> On Nov 27, 2016, at 2:11 PM, Gilles <[hidden email]>
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12