Skip to content
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

Closed
mp911de opened this issue Aug 18, 2016 · 12 comments
Closed

Jedis should provide pre-release binaries/snapshots #1369

mp911de opened this issue Aug 18, 2016 · 12 comments

Comments

@mp911de
Copy link
Contributor

mp911de commented Aug 18, 2016

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.

@HeartSaVioR
Copy link
Contributor

HeartSaVioR commented Aug 18, 2016

Since I'm involved in Apache project, I like release candidate in release process.
One thing I'm wondering is that does Jedis really have early adopters or steady contributors who can check for new release candidate more thoughtfully than our unit tests.

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.

@mp911de
Copy link
Contributor Author

mp911de commented Aug 18, 2016

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 SNAPSHOTs to eagerly discover issues.

Here's a link that contains a guide how to install deployment to Sonatype's. The only missing bit is filtering for SNAPSHOT in the pom.xml.

@HeartSaVioR
Copy link
Contributor

@mp911de
I'm OK to build SNAPSHOT (nightly, or every commit by Travis CI) for all active version lines.
This should be automated and we don't need to take much time to care.

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?

@marcosnils
Copy link
Contributor

@mp911de @HeartSaVioR

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.

mp911de added a commit to mp911de/jedis that referenced this issue Sep 30, 2016
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
@gkorland
Copy link
Contributor

@marcosnils is there any progress with that?

@marcosnils
Copy link
Contributor

Not for the moment.

@gkorland
Copy link
Contributor

gkorland commented Aug 20, 2018

I think it's very important so people can use the 3.0.0-SNAPSHOT easily.
We have a pending PR #1399

@gkorland
Copy link
Contributor

gkorland commented Aug 23, 2018

Until we'll have an official one I published a milestone artifact with the latest on the maven main repository
https://mvnrepository.com/artifact/com.redislabs/jedis

<dependency>
    <groupId>com.redislabs</groupId>
    <artifactId>jedis</artifactId>
    <version>3.0.0-m1</version>
</dependency>

@gkorland
Copy link
Contributor

@marcosnils thanks to @xetorthio I can now have access to the sonatype account and can release new artifacts.
Two immediate steps I think we should take:

  1. Release SNAPSHOTS from the master
  2. Release 3.0.0-M1 as a first milestone release for the 3.0.0

@marcosnils
Copy link
Contributor

@gkorland LGTM!.

@sazzad16
Copy link
Collaborator

It has been sometime that the snapshots are being published.

E.g. at this moment

  <repositories>
    <repository>
      <id>snapshots-repo</id>
      <url>https://oss.sonatype.org/content/repositories/snapshots</url>
    </repository>
  </repositories>

and

  <dependencies>
    <dependency>
      <groupId>redis.clients</groupId>
      <artifactId>jedis</artifactId>
      <version>3.5.0-SNAPSHOT</version>
    </dependency>
  </dependencies>

Copy link

This issue is marked stale. It will be closed in 30 days if it is not updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants