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