Le dim. 9 juin 2019 à 21:52, Karl Heinz Marbaise <khmarba...@gmx.de> a écrit : > > Hi, > > first I don't understand why you really like to 1.0-alpha or somehting > similar? > > Why not following semantical versioning and say if it's not yet 1.0.0 > than just simply release a 0.X.Y version. This makes clear the version > is not yet 1.0.0 and not finished and can be changed/break things..
Assuming version is "0.1", what is the (top-level) package name? AFAIK, all Commons libraries use the convention 1.X -> o.a.c.numbers 2.X -> o.a.c.numbers2 > This can be done also for things on going to 2.0.0... this means it's > major version change which is not compatible with 1.X.X... What is the package name in "2.0.0"? > What will tell me a version 2.0.0-alpha/beta? So this will tell people > there could be bugs in there? But isn't that always the case... I'm not sure we agree on the premises, so it's hard to answer. > > so why not naming the version 2.0.0 and if there is a bug just create a > 2.0.1, 2.0.2 etc. If you have enhancement in funcionality you produce > 2.1.0 etc. and so on..if you really are not compatible with 2.X than you > have to name it 3.0.0...(based on that you can use things like jcmpapi, > revapi etc. which are made for exactly those purposes). I'm not discussing tools to check compatibility; that's the point here: not care about compatibility or stability in "X.Y-betaZ", just that there won't be JAR hell if several are used together. > > So furthermore based on the idea of changing package names? Are you > really want to do so? That will break each code every time you change > the version? And what kind of problem are you trying to solve? That's what we've always done (cf. above), to avoid JAR hell. > If I'm in the position to check a new version of a library I just simply > upgrade the version (in my pom file or gradle file) and see if > everything works (build, tests)..If it's fine I simply continue.. That's > an easy way of upgrading things (or doing that automatically). > > If I need to change my code (based on package name changes) If I want to > upgrade to a newer version of a library except for cases where major > version changes this will make the acceptance harder than it needs to be. Am I correct that, contrary to what we've always done, you suggest, instead of the above: 1.X -> o.a.c.numbers 2.X -> o.a.c.numbers (same package name) ? > > Another thing I see in the discussion about changing groupId/artifactId > for a change in version? Simply to say that: It is not intended for such > things. The intended element for this is the version which could be > expressed by that (see above). IIUC, that concurs with a "yes" to my previous question. > > Suppose you will change the groupId/artifactId. You will get conflicting > packages/class names. You could have different dependencies in your > project (groupId/artifactId) are different but contain the same package > and clashing classnames. > > So the consequence would be to change the package names as well? Of course (cf. above and previous messages in this thread). > > The result would be duplicated classes of the same content within > different packages (or slightly different classes; much worse)? The price to pay for avoiding JAR hell. It's up to the user to not depend on different major versions, if doesn't need to. > Much > more complicated and does not really solve the problem cause in the end > this can not be solved by using things like that (alphas/betas changing > maven coordinates). I don't understand. How would you provide JARs for testing purposes? > The consumer of a lib has to check it's code if it's working or not via > Tests and CI system. With this proposal, the main purpose is *not* to test users' codes, but to ensure that the library is correctly designed. If not, with the current convention for Commons release, we'd ship 1.0 -> o.a.c.numbers and, when a flaw is discovered, say, the next day, we'd have to prepare for 2.0 -> o.a.c.numbers2 I prefer the flaw to be discovered in 1.0-beta1 -> o.a.c.numbers.beta1 so that when it's ironed out we can ship 1.0 -> o.a.c.numbers > > Finally one more thing about the whole discussion: > > The Java Module System. > > Changing packages etc. will simply not work cause the module-info file > contains the packages which are exported or not ... ? Of course, the module name would change too. > apart from that using > maven-shade-plugin will break modules which means that will break > anything in such cases. So that would a complete blocker for JDK9+ > (Why would you like to use maven-shade-plugin? You have separated > modules which can be consumed separately ..?) The plugin was mentioned just as a means to automate the renaming of the packages. > > Furthermore If you are running on module path you have no classpath > anymore which means you have only a single module name which must be > unique..(a little bit like groupId/artifactId). So? If we change it, it's unique. > > Some thought of mine. I probably did not understand your point(s). Regards, Gilles > > Kind regards > Karl Heinz Marbaise > > On 04.06.19 14:42, Gilles Sadowski wrote: > > Hello. > > > > Does someone see a practical way to automate package names > > and source files conversions so that each all alpha/beta releases > > can be used together (e.g. to compare their behaviours). > > > > I mean, for release version "1.0-alpha1", the top-level package > > name "o.a.c.compid" would be turned into "o.a.c.compid.alpha1". > > > > This would also solve issues with compatibility checkers (with the > > added bonus that JAR hell could never happen). > > > > Couldn't the "shade" plugin be put to use (so that all artefacts have > > their top-level package transparently set to "o.a.c.compid.alpha1" > > and all the tools operate on that)? > > > > > > Regards, > > Gilles > > > > --------------------------------------------------------------------- > > 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
