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 <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
