Suggestion: transfer repo to go-jose/jose
zrhmn opened this issue · 10 comments
As of right now, the GitHub org go-jose does not exist. It can be created and jose can be transferred to that org, which makes the overall package path: github.com/go-jose/jose
That's desirable because then stable versions of the package can be imported as gopkg.in/jose.v1
As it stands now, either the package github.com/SermoDigital/jose can be imported, which will download the package as it is on master branch. If one wants the v1 branch, they would do something like github.com/SermoDigital/jose/tree/v1 which does not quite work when importing said package. Another option would be to use gopkg.in/SermoDigital/jose.v1 which works, and that is what I'm using right now. But gopkg.in/jose.v1 is shorter, and much better IMO.
cc: @JoshAmato
I thought about doing it myself: create an organization go-jose and then fork SermoDigital/jose to go-jose/jose. That would actually have been easier; I could then use the gopkg.in/jose URI and the existing software that use github.com/SermoDigital/jose URI wouldn't break. But I can't do that because:
- This is your code and as such you should own the repo that contains it
- That will require me to manage the go-jose/jose repo, update the fork and merge with upstream when there's changes or new version tags, which I don't wanna do
- This is something that I wanted, and I don't know if it's the right thing for everybody and thus I can't seek to impose this on the devs who develop and consume the jose package.
So you should either resolve or close this issue.
Alright. I'll do it.
I'll do it and let you know and then you can close the issue. 👍 Thanks a bunch.
Update: Done... See:
thanks, I'll close this when I add the link to the README :)
I've run into a problem... As expected 😂
The issue is the go package in this repo has internal references to github.com/SermoDigital/jose/* but the package pointed by gopkg.in/jose.v1 is expected to have references to gopkg.in/jose.v1/* instead. Now it's easy to sort this problem out, by simply replacing the references. But that makes it a problem to manage the git tree. If I make the changes and push them in a new commit on the master branch on the go-jose/jose repo, and then move the v1.0 tag to the most recent commit, v1.0 contains changes that were made after the v1.0 tag on the original (SermoDigital/jose) repo...
This is not as straightforward as I had expected. I don't know if this "experiment" is worth continuing. I would really appreciate your input on this. I personally think I was wrong about doing the gopkg.in/jose.v1 thing in the first place and should quit it now.
Edit: Sorry for wasting your time.
Update:
I have figured out a way to address the issue mentioned above... The original master and v1 branch on the go-jose/jose fork have been moved to go-jose/jose#SermoDigital/master and go-jose/jose#SermoDigital/v1 respectively. These should reflect, and take merges from this repo. The master branch on go-jose/jose takes a merge from the SermoDigital branches on version tags, and contains references to gopkg.in URI instead of github.com URI.
In short, if you accept merge requests to master or v1, I should be able to merge them to go-jose/jose and if you create a version tag, I should merge the SermoDigital/master branch to master branch (on the go-jose/jose repo) and create the same version tag there...
I dunno, is this getting to complicated? Sorry again. 😞
doesn't seem too complicated to me. just as long as you're fine with it.
Have updated the README with a link 😃
This is somewhat unnecessary. Most Go package managers are now able to point to specific versions or commits, and the Go dep tool is something everyone should be moving toward, while many projects are deprecating gopkg.in