On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible <joerg.schai...@gmx.de> wrote:
> Sorry, for me this is going down the wrong road. For me different versions > mean different components. Allowing multiple versions for modules in one > component will exactly open the can of worms Gilles described below. We had > that already with Jakarta. > +1 and we do not need a Commons within Commons. For the case: commons-modproj-foo-1.0 commons-modproj-bar-1.1 You'd just release commons-modproj-foo-1.0 commons-modproj-bar-1.0 and then commons-modproj-foo-1.1 commons-modproj-bar-1.1 If nothing has changed in commons-modproj-foo between 1.0 and 1.1, then that's fine. You just get all your matching modules and you are done. > I still propose commons-rng-tools as separate component. Because of this > mail. KISS. > I'm not even in favor of that. Commons is already loose ecosystem of components, having sibling components will fog things up IMO. It's not just what's compatible with what according to some guidelines, it's more what has been tested with what so I can know for sure what will work. When I get Commons Foo 1.3 and it has 10 modules, I know it's all MEANT to work together, I KNOW it was all BUILT and TESTED together. Just keep it all in one component and make user's life easy. Gary > > - Jörg > > Gilles wrote: > > > Hello. > > > > As a follow-up of > > http://markmail.org/message/jckbknphndecglns > > and > > http://markmail.org/message/f3g33kvevf52xohf > > I summarize what I think should be allowed for versioning > > modularized components of the "Commons" project. > > > > Assume there are two modules in project "Commons ModProj": > > commons-modproj-foo > > commons-modproj-bar > > > > Their respective "top-level package" would be: > > org.apache.commons.modproj.foo > > org.apache.commons.modproj.bar > > > > I propose that versioning of the modules are independent > > (as if they were different components). > > > > As said in the referred posts, it would allow the version > > numbers to reflect the actual state of each of the module. > > For example, assume that this proposal is validated, and > > that > > commons-modproj-foo-1.0 > > commons-modproj-bar-1.1 > > were released. > > > > Note: for the sake of exercising the version changes, all the > > cases below happen in the sequence shown (ala "switch" with > > "case" without "break"). > > > > === Case (A) === > > > > We must release a non-BC upgrade of "bar". > > Hence, we would release > > commons-modproj-bar-2.0 > > with "top-level package" > > org.apache.commons.modproj.bar2 > > > > Advantage: applications that only use module "foo" are unaffected. > > > > === Case (B) === > > > > Assume that "bar" depends on "foo". > > > > -- Case (B1) -- > > We release a BC version of "foo": > > commons-modproj-foo-1.1 > > > > * Case (B1+) > > The upgrade consists of new features only. > > Module "bar" is totally unaffected (what worked with foo-1.0 > > works the same with foo-1.1) and no new release of "bar2" > > will happen. > > > > Advantage: users of "bar2" only will not wonder whether they > > should upgrade (if they did not intend to use new features, > > there is no reason for them to upgrade). > > > > * Case (B1-) > > The upgrade consists of bug fixes. > > Both modules will be released, i.e. > > commons-modproj-foo-1.1.1 > > commons-modproj-bar2-2.0.1 > > > > This will trigger an upgrade for all users (who care about > > correctness). > > > > -- Case (B2) -- > > We release a non-BC version of "foo": > > commons-modproj-foo2-2.0 > > with "top-level package" > > org.apache.commons.modproj.foo2 > > > > * Case (B2+) > > The upgrade is purely a re-design. > > > > The development team is free to (major) release the new > > "foo2-2.0" without having upgraded "bar2", i.e. latest "bar2" > > (2.0.1) still uses "foo-1.1.1". > > > > ~ Case (B2+sync) > > Team is able to provide, at time of release, a bridge and > > release > > commons-modproj-bar2-2.1 > > so that users of "bar2-2.1" will transparently use > > "foo2-2.0" > > (in place of "foo-1.1.1"). > > > > ~ Case (B2+async) > > Team is able to provide (or improve) the bridge later on, > > i.e. release > > commons-modproj-foo2-2.1 > > commons-modproj-bar2-2.2 > > so that users of "bar2" only will transparently use > > "foo2-2.1" > > (in place of "foo-1.1.1" or "foo2-2.0"). > > > > Advantages: > > - Redesigned "foo" can be released without worrying about > > upgrading "bar" (RERO). > > - Users of "bar2" only can either not worry about upgrade, > > or just update their version dependency (not changing a > > single line of code). > > > > * Case (B2++) > > Previous re-design turned out to be sub-optimal. > > > > A new major "foo" is released: > > commons-modproj-foo3-3.0 > > with "top-level package" > > org.apache.commons.modproj.foo3 > > > > [Same (non-)consequences for "bar2" as previous case.] > > > > * Case (B2-) > > An upgrade also contains bug-fixes. > > > > A new major "foo" will be released, i.e. > > commons-modproj-foo4-4.0 > > with "top-level package" > > org.apache.commons.modproj.foo4 > > together with a new major "bar" > > commons-modproj-bar3-3.0 > > with "top-level package" > > org.apache.commons.modproj.bar3 > > > > Here the upgrade of "bar" will force its users to think > > about whether they need to upgrade (whether they are > > impacted by the bugs or they want to have support usually > > provided for latest version only). > > > > === Case (C) === > > > > People want to completely redesign the whole "ModProj" functionality. > > > > We can release > > commons-modproj2-foo-1.0 > > commons-modproj2-bar-1.0 > > > > Their respective "top-level package" would be: > > org.apache.commons.modproj2.foo > > org.apache.commons.modproj2.bar > > > > > > At this point we'd have these modules officially released: > > commons-modproj-foo4-4.0 > > commons-modproj-bar3-3.0 > > commons-modproj2-foo-1.0 > > commons-modproj2-bar-1.0 > > all happily living together[1]; and improvements can be easily > > exchanged among the different lines of development (e.g. via > > "git" branches). > > > > Obviously, the significant change is that version numbers are > > tied to modules, not component. Does that pose a problem?[2] > > [It should be clear that having the same version numbers for > > "foo" and "bar" would be a pure coincidence.] > > > > In particular, version and package changes are confined to > > where code changes happen; they follow the development of > > specific features (while non-impacted code is not forced to > > adopt a version that is actually related to "foreign" code). > > > > Another fundamental advantage, community-wise, is that it is > > conducive to maintaining a good relationship among developers > > even if they want to "scratch different itches".[3] > > > > In effet, this scheme would allow to group codes by "broad" > > subject while module management could be fine-grained,[4] > > up to using specific version suffixes (such as "-dev" or > > "-extras") to convey intended use or audience or level of > > support... > > > > > > Regards, > > Gilles > > > > [1] Provided the dependencies are correct of course. > > [2] According to Stian, it does not (IIRC). > > [3] Whereas the current scheme turned different POV into personal > > fights, with punctual winners and losers (however gracefully > > they think they can handle it) but an enduring overall loss > > for the community. > > [4] On a par with the varying levels of development (for whatever > > reasons, such as lack of time or lack of contributors) of those > > modules. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
