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.. 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 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... 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). 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? 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. 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). 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? The result would be duplicated classes of the same content within different packages (or slightly different classes; much worse)? 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). The consumer of a lib has to check it's code if it's working or not via Tests and CI system. 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 ...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 ..?) 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). Some thought of mine. 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
