commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: [ALL] Version number(s) for modular components
Date Sat, 26 Nov 2016 17:06:56 GMT
Sorry, for me this is going down the wrong road. For me different versions 
mean different components. Allowing multiple versions for modules in one 
component will exactly open the can of worms Gilles described below. We had 
that already with Jakarta.

I still propose commons-rng-tools as separate component. Because of this 
mail. KISS.

- Jörg

Gilles wrote:

> Hello.
> 
> As a follow-up of
>    http://markmail.org/message/jckbknphndecglns
> and
>    http://markmail.org/message/f3g33kvevf52xohf
> I summarize what I think should be allowed for versioning
> modularized components of the "Commons" project.
> 
> Assume there are two modules in project "Commons ModProj":
>    commons-modproj-foo
>    commons-modproj-bar
> 
> Their respective "top-level package" would be:
>    org.apache.commons.modproj.foo
>    org.apache.commons.modproj.bar
> 
> I propose that versioning of the modules are independent
> (as if they were different components).
> 
> As said in the referred posts, it would allow the version
> numbers to reflect the actual state of each of the module.
> For example, assume that this proposal is validated, and
> that
>    commons-modproj-foo-1.0
>    commons-modproj-bar-1.1
> were released.
> 
> Note: for the sake of exercising the version changes, all the
> cases below happen in the sequence shown (ala "switch" with
> "case" without "break").
> 
> === Case (A) ===
> 
> We must release a non-BC upgrade of "bar".
> Hence, we would release
>    commons-modproj-bar-2.0
> with "top-level package"
>    org.apache.commons.modproj.bar2
> 
> Advantage: applications that only use module "foo" are unaffected.
> 
> === Case (B) ===
> 
> Assume that "bar" depends on "foo".
> 
>   -- Case (B1) --
>     We release a BC version of "foo":
>       commons-modproj-foo-1.1
> 
>    * Case (B1+)
>        The upgrade consists of new features only.
>        Module "bar" is totally unaffected (what worked with foo-1.0
>        works the same with foo-1.1) and no new release of "bar2"
>        will happen.
> 
>        Advantage: users of "bar2" only will not wonder whether they
>        should upgrade (if they did not intend to use new features,
>        there is no reason for them to upgrade).
> 
>    * Case (B1-)
>        The upgrade consists of bug fixes.
>        Both modules will be released, i.e.
>          commons-modproj-foo-1.1.1
>          commons-modproj-bar2-2.0.1
> 
>        This will trigger an upgrade for all users (who care about
>        correctness).
> 
>   -- Case (B2) --
>     We release a non-BC version of "foo":
>       commons-modproj-foo2-2.0
>     with "top-level package"
>       org.apache.commons.modproj.foo2
> 
>       * Case (B2+)
>           The upgrade is purely a re-design.
> 
>           The development team is free to (major) release the new
>           "foo2-2.0" without having upgraded "bar2", i.e. latest "bar2"
>           (2.0.1) still uses "foo-1.1.1".
> 
>           ~ Case (B2+sync)
>             Team is able to provide, at time of release, a bridge and
>             release
>               commons-modproj-bar2-2.1
>             so that users of "bar2-2.1" will transparently use
> "foo2-2.0"
>             (in place of "foo-1.1.1").
> 
>           ~ Case (B2+async)
>             Team is able to provide (or improve) the bridge later on,
>             i.e. release
>                commons-modproj-foo2-2.1
>                commons-modproj-bar2-2.2
>             so that users of "bar2" only will transparently use
> "foo2-2.1"
>             (in place of "foo-1.1.1" or "foo2-2.0").
> 
>          Advantages:
>           - Redesigned "foo" can be released without worrying about
>             upgrading "bar" (RERO).
>           - Users of "bar2" only can either not worry about upgrade,
>             or just update their version dependency (not changing a
>             single line of code).
> 
>       * Case (B2++)
>           Previous re-design turned out to be sub-optimal.
> 
>           A new major "foo" is released:
>             commons-modproj-foo3-3.0
>           with "top-level package"
>             org.apache.commons.modproj.foo3
> 
>           [Same (non-)consequences for "bar2" as previous case.]
> 
>       * Case (B2-)
>           An upgrade also contains bug-fixes.
> 
>           A new major "foo" will be released, i.e.
>             commons-modproj-foo4-4.0
>           with "top-level package"
>             org.apache.commons.modproj.foo4
>           together with a new major "bar"
>             commons-modproj-bar3-3.0
>           with "top-level package"
>             org.apache.commons.modproj.bar3
> 
>           Here the upgrade of "bar" will force its users to think
>           about whether they need to upgrade (whether they are
>           impacted by the bugs or they want to have support usually
>           provided for latest version only).
> 
> === Case (C) ===
> 
> People want to completely redesign the whole "ModProj" functionality.
> 
> We can release
>    commons-modproj2-foo-1.0
>    commons-modproj2-bar-1.0
> 
> Their respective "top-level package" would be:
>    org.apache.commons.modproj2.foo
>    org.apache.commons.modproj2.bar
> 
> 
> At this point we'd have these modules officially released:
>    commons-modproj-foo4-4.0
>    commons-modproj-bar3-3.0
>    commons-modproj2-foo-1.0
>    commons-modproj2-bar-1.0
> all happily living together[1]; and improvements can be easily
> exchanged among the different lines of development (e.g. via
> "git" branches).
> 
> Obviously, the significant change is that version numbers are
> tied to modules, not component.  Does that pose a problem?[2]
> [It should be clear that having the same version numbers for
> "foo" and "bar" would be a pure coincidence.]
> 
> In particular, version and package changes are confined to
> where code changes happen; they follow the development of
> specific features (while non-impacted code is not forced to
> adopt a version that is actually related to "foreign" code).
> 
> Another fundamental advantage, community-wise, is that it is
> conducive to maintaining a good relationship among developers
> even if they want to "scratch different itches".[3]
> 
> In effet, this scheme would allow to group codes by "broad"
> subject while module management could be fine-grained,[4]
> up to using specific version suffixes (such as "-dev" or
> "-extras") to convey intended use or audience or level of
> support...
> 
> 
> Regards,
> Gilles
> 
> [1] Provided the dependencies are correct of course.
> [2] According to Stian, it does not (IIRC).
> [3] Whereas the current scheme turned different POV into personal
>      fights, with punctual winners and losers (however gracefully
>      they think they can handle it) but an enduring overall loss
>      for the community.
> [4] On a par with the varying levels of development (for whatever
>      reasons, such as lack of time or lack of contributors) of those
>      modules.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message