On Sat, Nov 26, 2016 at 9:28 AM, Rob Tompkins <chtom...@gmail.com> wrote:
> I've always thought that versioning sat at a repository level. When you > check out (or clone or whatever) code it feels counterintuitive to have > several different potential versions floating around in what you just got. > So I would argue for the general guideline of one repository, one overall > version. > Exactly, as I wrote earlier, this proposed version salad is a guarantee for confusing, what's compatible with what, what's been tested with what. Is the build going to depend on a matrix of test jars and runtime jars to make sure it all works? In short: - KISS: Keep it in one component, especially for 1.0! Even reconsider going back to a single module. Or, - Go TLP and do whatever you want. Gary > Cheers, > -Rob > > > On Nov 26, 2016, at 12:06 PM, Jörg Schaible <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. > > > > 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-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > 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
