New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jedis should provide pre-release binaries/snapshots #1369
Comments
Since I'm involved in Apache project, I like release candidate in release process. Back to the recent issue and talking about that a bit, in my perspective this issue was occurred because we modified unit tests which checks return type. That pull request even skipped pair review. If we can automate SDR tests to every snapshot builds of Jedis or RC of Jedis, it makes sense. Other than that, we need to answer ourselves that who would test for us. |
Providing snapshots/release candidates creates options although it may lack a broad adoption. You can tell users to switch to a SNAPSHOT to test a particular case (without the need to rebuild the driver yourself). Release cycles with snapshot/release candidate(s)/GA release are beneficial for short feedback cycles and discovering issues early, yet it does not cure all pains (because people are on vacation, not motivated in updating, …). You provide a possibility to test your library. No RC/Snapshots means a higher barrier to give a new version a try. I don't think it's just an issue to Spring Data Redis only. We run builds in several projects against different driver versions, some of them are Here's a link that contains a guide how to install deployment to Sonatype's. The only missing bit is filtering for |
@mp911de I'd be much appreciated if you provide a patch for that since I don't want to spent time to dig (explore?). Having RCs in release process is different as you said. It can't be automated since it's more alike process, so it requires more time (linearly to the attempt of RCs) for release manager, and technically only @xetorthio is a release manager. (I think it would be better to correct this.) We have three active collaborators including owner who all have our daily jobs and AFAIK we all don't use Redis for our daily jobs (even @xetorthio and @marcosnils are not using Java) so we need to minimize (opposite to expand) the processes regarding Jedis. I had been spending more time to Jedis before I was involved to Apache Storm. Before that I could handle more things like this case, and I can't do that now even though contributing Apache Storm is my daily job now. It requires my whole concentration for that. @xetorthio @marcosnils What do you think? |
I do also believe that it should be amazing to have nightly builds or RC's. We need the invervention of @xetorthio as he's the only one allowed to publish to Sonatype. |
TravisCI now deploys jedis SNAPSHOT artifacts to Sonatype's OSS Snapshot Repo if: * The build is not a pull-request * Travis has secure env variables set up * The artifact version ends with SNAPSHOT Fixes redisgh-1369
@marcosnils is there any progress with that? |
Not for the moment. |
I think it's very important so people can use the 3.0.0-SNAPSHOT easily. |
Until we'll have an official one I published a milestone artifact with the latest on the maven main repository
|
@marcosnils thanks to @xetorthio I can now have access to the sonatype account and can release new artifacts.
|
@gkorland LGTM!. |
It has been sometime that the snapshots are being published. E.g. at this moment
and
|
This issue is marked stale. It will be closed in 30 days if it is not updated. |
Jedis is a widely used client for Redis. Each release comes with a number of changes that are only available with own/custom snapshots build or by awaiting the final release.
It's not possible for users to run tests against development/pre-release binaries because these are not available.
Please provide at least snapshot builds (in Sonatype's OSS Snapshot repo), better, release candidates as part of the release process. Users can include pre-release binaries in own builds and verify for breaking changes.
Publishing snapshots with TravisCI is feasible; I can support you if you want. Publishing pre-releases requires changes in the release process and is more a process issue than a technical.
The text was updated successfully, but these errors were encountered: