On Sun, Nov 27, 2016 at 1:19 PM, Benedikt Ritter <brit...@apache.org> wrote:
> Hello Gilles, > > Gilles <gil...@harfang.homelinux.org> 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 <chtom...@gmail.com> > > > 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 <brit...@apache.org> > > >> wrote: > > >> > > > >> > I'm also in the "one-version per repository"-camp. > > >> > > > >> > Benedikt > > >> > > > >> > Stian Soiland-Reyes <st...@apache.org> 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" <joerg.schai...@gmx.de> > > >> wrote: > > >> >>> > > >> >>> Gary Gregory wrote: > > >> >>> > > >> >>>> 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. > > >> >>> > > >> >>> We already have dbcp depending heavily on pool. > > >> >>> > > >> >>> - Jörg > > >> >>> > > > > > > --------------------------------------------------------------------- > > 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
