I'm in need of code that only exists in the master at the moment, and the docs specifically mention a version called 2.0.0.BUILD-SNAPSHOT, but I'll be damned if I can figure out which repository is hosting such a build. Anyone have any clues?
Also, is there any information published about release schedules? I'm loath to develop against the 1.x API because I want the retry and recovery functionality (which doesn't work in either of the 2.0.0 milestone builds, hence my need for a snapshot), but I don't want to commit to an unreleased library without some sense of when a release might happen.
The BUILD-SNAPSHOT you can find in the https://repo.spring.io/snapshot. So, you should configure that for your project.
The next Spring Kafka 2.0.0.RC1 is scheduled for this June 28.
You can find that info on the project page as well: https://github.com/spring-projects/spring-kafka/milestone/20
Related
Here are the release notes for Spring Boot 2.3.1
https://github.com/spring-projects/spring-boot/releases/tag/v2.3.1.RELEASE
I've searched everywhere in the Wiki, in Issues and in the code, but I can't find where these are being created.
Is this a manual process or automated in some way?
I'd love to take a similar approach in my projects but prefer not to do it manually if possible.
Does anyone know of any resources that describe how to generate release notes in this format with some level of automation?
hello if you look carefully in spring boot github repo, you will have this
spring-boot/ci/pipeline.yml
this is where they have their build/release workflow
and the file below is the script use to generate the github release note
https://github.com/spring-projects/spring-boot/blob/main/ci/scripts/generate-changelog.sh
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!
The question seems easy, but according to my research, the maven repository http://repo.maven.apache.org/maven2/org/primefaces/primefaces/ has only major releases 5.2,5.3,...,6,2
what I want exactly is to use the version 5.2.9 in order to correct the problem of the reCAPTCHA by implementing its v2, the use of the version 5.3 will have much impact on the developed application.
X.Y.Z releases are only available for paying customers as an elite release. You can then download the jar in a portal and put it in your own maven repo. They are not available in any public repository.
What you could try to do is to compare the sources of the 5.2 and 5.3 release regarding the captcha and just backport those. Still, really upgrading (to 6.2) is a better choice
If you have luck, maybe 5.3.RC1, which implements reCAPTCHA v2, is close to 5.2.9. You can get 5.3.RC1 via primefaces repo: https://repository.primefaces.org/org/primefaces/primefaces/5.3.RC1/
I work with a small team that manages a large number of very small applications (~100 Portlets). Each portlet has its own git repository. During some code I was reviewing today, someone made a small edit, and then updated their pom.xml version from 1.88-SNAPSHOT to 1.89-SNAPSHOT. I added a comment asking if this is the best way to do releases, but I don't really know the negative consequences of doing this.
Why not do this? I know snapshots are not supposed to be releases, but why not? What are the consequences of using only snapshots? I know maven will not cache snapshots the same as non-snapshots, and so it may download the artifact every time, but let's pretend the caching doesn't matter. From a release-management perspective, why is using a SNAPSHOT version every time and just bumping the number a bad idea?
UPDATE:
Each of these projects results in a war file that will never be available on a maven repo outside of our team, so there are no downstream users.
The main reason for not wanting to do this is that the whole Maven eco-system relies on a specific definition of what a snapshot version is. And this definition is not the one you're setting in your question: it is only supposed to represent a version currently in active development, and it is not suppose to be a stable version. The consequence is that a lot of the tools built around Maven assumes this definition by default:
The maven-release-plugin will not let you prepare a release with a snapshot version as released version. So you'll need to resort to tagging by hand on your version control, or make your own scripts. This also means that the users of those libraries won't be able to use this plugin with default configuration, they'll need to set allowTimestampedSnapshots.
The versions-maven-plugin which can be used to automatically update to the latest release version won't work properly as well, so your users won't be able to use it without configuration pain.
Repository managers, like Artifactory or Nexus, comes built-in with a clear distinction of repositories hosting snapshot dependencies and release dependencies. For example, if you use shared Nexus company-wide, it could be configured to purge old snapshots so this would break things for you... Imagine someone depends on 1.88-SNAPSHOT and it is completely removed: you'll have to go back in time and redeploy it, until the next removal... Also, certain Artifactory internal repositories can be configured not to accept any snapshots, so you won't be able to deploy it there; the users will be forced, again, to add more repository configuration to point at those that do allow snapshots, which they may not want to do.
Maven is about convention before configuration, meaning that all Maven projects should try to share the same semantics (directory layout, versioning...). New developers that would access your project will be confused and lose time trying to understand why your project is build the way it is.
In the end, doing this will just cause more pain on the users and will not simplify a single thing for you. Probably, you could make it somewhat work, but when something is going to break (because of company policy, or some other future change), don't act surprised...
Tunaki gave a lot of reasonable points why you break Maven best practices, and I fully support that view. But even if you don't care about "conventions of other companies", there are reasons:
If you are not doing CI (and consider every build as potential release), you need to distinguish between versions which should go productive and those who are just for testing. If everything is SNAPSHOT, this is hard to do.
If someone (accidentally) deploys a second 1.88-SNAPSHOT, it will be the new 1.88-SNAPSHOT, hiding the old one (which is available by a concrete timestamp, but this is messy). Release versions cannot be deployed twice.
http://www.springsource.org/downloads/sts-ggts
I am trying to download new STS tool. On the above site I find
Milestone Version and Release Version. Can anyone tell me what these terms mean? Which is Users version to be used and is completely developed and not under-development?
The release version is the one you want, "release" means it's considered to be done and ready for the public. "Milestone" means it's a stable checkpoint made available for community developers to test. You'd pick the milestone one if there are new features or bugfixes you want to try out that haven't been included in a release yet.