Can anyone tell me, if it's possible to add prefixes to the version number when using the maven release-plugin for version-management and releasing? Unfortunately I have no easy way to test it and since I couldn't find anything useful about this topic, I thought why not just ask the SO-community :)
(With prefixes I mean naming something my-service-V10.7.3 instead of my-service-10.7.3)
Basically you can name the released version anything you want (using the interactive mode or the releaseVersion property).
So your build job or whoever calls the release plugin can determine the release version number by itself and hand it to the maven job.
Automatically adding a prefix is not possible
I would, however, advise against using version prefixes. The violate conventions.
Try to go for established version schemes, if you really need to add anything, use 10.7.3.GA or something like that. This will also play nice with plugins and tools that determine which version is newer.
Related
I had a general query about maven versioning numbers. Are there some specific rules to giving version numbers to SNAPSHOT or RELEASE for a maven based project?
E.g. we have multiple rules for variable naming like we cannot start with a digit. Likewise, do we have any such specific rules violating which does not allow the artifact gets published?
I came across such a situation where I provided version number like X.YY-SNAPSHOT(say 2.56-SNAPSHOT) and it failed to publish properly. When I changed that to X.Y.Z-SNAPSHOT, it worked fine. I tried to find information related to this but couldn't hit any properly.
Please enlight me here.
No, technically, you can use any combination of numbers, dots, hyphens and letters as a version number. Something like 2.56-SNAPSHOT is totally fine.
Of course, some organisations might introduce further restrictions, e.g. that a version number has to have the form x.y.z-SNAPSHOT but this is not a Maven thing.
If I am working on multiple projects where different Go versions are required to build them, how would I elegantly set up my development environment to deal with this?
Each project has its own Makefile which at some point or the other would invoke Go commands. The issue is that some projects require different versions of Go, but the Makefiles simply use go build. My solution so far has been to simply add whichever Go version I needed to the PATH variable, e.g. project 1 requires go1.12.10, so I just run
export PATH=<path_to_go1.12.10_>/bin>:$PATH
And when I want to build project 2 which requires go1.13.6
export PATH=<path_to_go1.13.6>/bin:$PATH
This works, but is there a more elegant solution? Modifying the projects' build systems is not something I can do, at least not in the short term.
Go build has no native way to set the version to build with, so you are stuck either setting the path like you are now, or executing explicitly using /<path_to_go1.13.6>/bin/go.
For the versions that you implied you are working with, there really should be no incompatibilities between them and the latest version of go. On of Go's tenants is to preserve backwards compatibility under basically all circumstances. You would most likely be better off using go's latest version, and, if something is preventing you from upgrading the compiler, fixing that instead.
I'm working with a Grails application version 2.2.4 and I need a procedure for upgrade to latest version (I hope it can be possible). I have thought as a first step to follow the indications of the official site, but that let me to upgrade to version 3.
I'd like to know if anyone already did it or have experience about that. How long take it?, the process and the main problems.
Many thanks in advance.
I think you need to follow both upgrade instructions. the one for 3.x and the 4.x.
start with the 3.x and them move to the 4.x changes.
Another approach I think may be better is to start an empty 4.x application and then start moving you code there. also check first that all the plugins that you are you sing have 3+ version.
The effort required to upgrade can change massively depending on multiple factors, including the size of the project, the quality of the original code, were plugins used and if so have they been updated or will the functionality need replacing, were deprecated taglibs used, e.g remoteFunction etc. etc.
There is not a great deal of difference between 3.x and 4.x so it makes sense to upgrade to 4.x.
Tackle it in stages from the basis of a new project, attempting to rebuild the project between stages.
Reestablish configuration, you don't have to use application.yaml (the default in 4.x) so can create an application.groovy with the same parameters as per your old project.
Move over domain objects but use a new database URL, compare the schema's between the old db and new db to ensure the database is the same. Unless you don't rely on GORM to recreate/update the schema.
Move over any other source and command objects ensuring the project will build. You may need to modify buildconfig at this stage to bring in dependencies and plugins.
Move over services, ensure all compiles and make sure transactions are behaving as intending.
Move over controllers ensuring any tests run successfully.
Move over the views.
Hopefully if the project is still building at this stage, you can run it!
I've recently been implementing a CI system for work. The way I understand maven versions is that it can be of the form x.x.x-y-z. We want to have nightly builds in our CI system and have it tagged as x.x.x-y where y would go up on every nightly build. The next development version would stay as x.x.x-SNAPSHOT. This way our version numbers don't go up like crazy, only the build number does. And we can pick a particular tag and promote it to testing/UAT/production etc.
However, when I try to do a release with the maven release plugin on x.x.x-SNAPSHOT it increments the next version to x.x.x+1-SNAPSHOT. Or I can have x.x.x-y-SNAPSHOT which is quite ugly.
Currently we have a python build script that we use to achieve this, but it is hard to maintain. We want to try to move to a more standardized system that allows us to have nightly builds without having version numbers go up like crazy and still be able to track which version of the code is running on which server.
Is there a way of setting up maven/Jenkins to do what I have described? Is there a better more standardized way to achieve similar functionality?
As a messy solution I am thinking of taking the relevant chunks out of the python script and running them with Jenkins. However, I know there has to be a more elegant way of doing this.
Edit: I'm using maven 3.2.1
I'm currently working on Maven tools for Project Dash. One of the open issues is how to handle mistakes.
Maven central says: Nothing published ever changes. This is because Maven never tries to figure out whether a release has changed (unlike for SNAPSHOTs).
But I might have to create a new "release" of, say, part of Eclipse 3.6.2. Which version number should I use? 3.6.2.1, 3.6.2-1, 3.6.2_1, 3.6.2pl1? Why?
The convention for version numbers is major.minor.build.
major is incremented when the public interface changes incompatibly. For example, a method is removed, or its signature changes. Clients using your library need to take care when using a library with a different major version, because things may break.
minor is incremented when the public interface changes in a compatible way. For example, a method is added. Clients do not need to worry about about using the new version, as all the functions they are used to seeing will still be there and act the same.
build is incremented when the implementation of a function changes, but no signatures are added or removed. For example, you found a bug and fixed it. Clients should probably update to the new version, but if it doesn't work because they depended on the broken behavior, they can easily downgrade.
The tricky issue here is that it sounds like you are modifying code written and released by somebody else. The convention here, as I have seen it, is to postfix the version number with either -yourname-version or just -version. For example, linux-image-2.6.28-27 is a likely name of a Ubuntu kernel image.
As Maven uses dashes to differentiate between artifact coordinates, however, I would recommend (very long-windedly, apparently) to just add .version to avoid confusing it. So 3.6.2.1 in this case.
Maven project versions are specified like this.
<major version>.<minor version>.<incremental version>-<qualifier>
As you do not want to change the version number you are looking for a qualifier. I do not know if there is a general recommendation for the name of the qualifier. The Spring people e.g. did something like this
2.5.6.SEC01
2.5.6.SR02
3.0.0.M3
They didn't use the hyphen/dash notation to seperate the qualifier.
What ever you do, you have to be careful regarding the ordering of versions! Have a look at the first link I added.
Update: Also have a look at #krzyk comment for recent changes/additions.
This is because Maven never tries to
figure out whether a release has
changed
That's in my opinion not the basic reason. The reason is to have reliable builds in the future. You define the versions in your pom and that's it. If someone would remove artifacts from maven central or become worse changing an existing artifact you can't be sure that your build will be working in the future...or an older build would work.
The version number is up to you...i would suggest to use 3.6.2.1.