Closed willcohen closed 5 years ago
@worace do you think we can get an alpha released? It'd be useful to get this into testing on a project we're working on.
Yeah, I don't really know of anything else to wait for, so I'll push a 3.0-rc now
OK @willcohen can you try this one out: https://clojars.org/factual/geo/versions/3.0.0-rc-0
Will try it out!
It seems like it's working pretty well -- does it sound right to you that all that remains are release notes and any documentation updates?
@willcohen yeah that seems right to me. Looking quickly through the list here, it seems like the main points are:
@willcohen sounds good. Somewhat related, I have been thinking about ways to better automate the release process for the package, hopefully in such a way that we can get it done via Travis on every merge to master.
I have a rough idea of how it could work, assuming I can create the appropriate bot credentials in Clojars and Github to let it push to the repo when needed:
Setup
Script
https://clojars.org/factual/geo/versions/3.0.0-rc-1
with cURL)git ls-remote --tags origin | grep "3.0.0-rc-1"
)for 2 + 3, if they aren't found, push them. I think the trickiest part here may be getting the proper GPG key setup for clojars within Travis.
I am going to play around with this a bit this morning and see if I can get a 3.0.0-rc-1
pushed with such a process.
Ok, part way there on the releasing.
The clojars push is working, but I need to figure out how to disable the multi-JDK build for deployment because it's currently trying to push it 3 times, and they get into a race and then 2/3 of them fail. You can see in this build, this job succeeds in pushing to clojars, and then the other 2 fail: https://travis-ci.org/Factual/geo/jobs/498482981
Secondly it looks like the git push isn't working. Log says:
3.0.0-rc-2 tag does not exist in GitHub. Will push it.
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/Factual/geo.git/'
Script failed with status 128
I think it is using the HTTPS instead of the SSH git remote, so I may need to update the script to swap that explicitly.
Something like this might help with limiting the deploy stage to 1 build
OK this is looking good now I think:
And after a few tries the clojars version and the git tag did eventually get there:
I don't have any more releases I need to push at the moment, but we can test this again next time we do.
Next challenge will be to get the codox build to automatically push from it as well, but I might save that for another day.
@worace Just made PRs #56 (adding one more thing to jts
) and #57 (fixing travis). If those look good, might be time for an rc-3 -- should I give that a shot? Is the process just changing the version number in project.clj
?
@willcohen I think that sounds great, and sorry we have sat on this for a while. Seems like no reason to keep waiting, so if you want to do another rc-3 for sanity checking we can do that, and then shortly after just push out 3.0 as far as i am concerned.
Sounds good, and looks like rc-3 worked correctly. I'll try it out this week -- unless anything comes up, I think 3.0 can be based on it.
With #61 I think everything's ready for 3.0, short of actually bumping the version number and having CI cut a release. The PR also has regenerated codox docs (do those deploy automatically once they get to master or is there something else to do?) and an updated README so that when the actual version bump happens, cljdoc will show correct version numbers. @worace
It looks like CI passed on master. Anything else before release?
No, I think it's good to go. I think you can just bump the version in project.clj to 3.0.0
and push that to master and the release CI job should handle the rest
Oop. Looks like it requires adding a tag and not just the project.clj. Will correct.
However, one final check before I actually push the tag and wrap this up. I am realizing (after checking clojars and only seeing rc-3), that there's still a dependency for noggit
, which was previously used for JSON parsing. This library no longer uses noggit (now it's jts2geojson: https://github.com/Factual/geo/commit/826ec1cc58afe31fe44b56d609302e4bc9581fdc). Any objections to me removing noggit from the dependencies before I add the tag? Still passes all tests even when removed.
Adding openj9 with #59 actually caused travis to stop running the deploy script (either to push the tag or push the release). After merging #62 (script runs again with https://travis-ci.org/Factual/geo/jobs/592767954), 3.0 should be deployable. @worace
Oop. Looks like it requires adding a tag and not just the project.clj. Will correct.
You mean a git tag? I thought the release script was supposed to push that on its own.
Oh i see your other comment
Adding openj9 with #59 actually caused travis to stop running the deploy script (either to push the tag or push the release
So we think it does work, but we had accidentally disabled it.
Correct, I accidentally disabled it. If CI still passes (and the release script looks like it's running again but choosing not to re-deploy rc-3) after #62, I'll bump the version again.
Note for the future: the release script saw the 3.0.0-rc-*
tags and decided that meant the 3.0.0
tag already existed: https://travis-ci.org/Factual/geo/jobs/592793680.
I manually pushed the 3.0.0
tag to deal with it for now, but we'll need to fix that eventually.
:tada: good to know about the script; maybe we can make the matching there stricter. Great to have this out though!
Yes! Thanks so much for all your help working through this release!
@worace are there any other changes you think would make sense for 3.0? Is it a good idea to get a first alpha out that uses all the updated dependencies?