@sgold I see 3.3.1 on jitpack and gitlab, thank you for your work on this!
I did forget that part.
To make the automatic build run you have to make a github release that creates the tag. Set it as a prerelease and then go back and turn it into a real release when the jars are up.
I went into the web interface and marked āv3.3.1-stableā as pre-release. I donāt see any evidence of deployment.
Should I delete the tag and recreate it through the web interface?
Yes. The tag has to be created through the web interface.
1 Like
Also, when you cut the release through the web, make sure you select the right branch for the tag.
ā¦thatās highlighted in my notes so apparently I screwed it up at least one time.
1 Like
In case itās helpful, here are my cryptic notes on the release process:
To add a tag: (don't do this)
git tag -m "release" -a v3.1.0-alpha3
git push origin v3.1.0-alpha3
To delete a tag (if you mess up):
git tag -d v3.1.0-alpha3
git push origin :refs/tags/v3.1.0-alpha3
To add a tag, cut a release now... make sure to select the right
branch for the tag.
To pretty commit a log between two versions:
git log v3.1.0-alpha3..v3.1.0-alpha4 --name-status --cherry
I then search/replace the e-mail addresses before posting it anywhere.
I use this regex which my editor supports: <[a-zA-Z0-9.]+@[a-zA-Z0-9.]+>
That regex misses e-mails with underscores and stuff, this one works better:
<.+@[a-zA-Z0-9.]+>
For branch creation:
git checkout -b <branch-name>
git push -u origin <local-branch-name>
git log v3.2.4-stable..v3.3.0-beta1 --name-status --cherry > v3.3.0-beta1.txt
Changes on MASTER that are not on the branch:
git log --cherry-pick origin/v3.3...origin/master
Many bothans died...
I kept them from the very first release I made so the first part is the old wayā¦ the one that now says (donāt do this). I donāt delete things from my notes as a rule.
Note: something you did must have built a release because there are 174 items in bintray waiting to be published.
Edit: do we trust them or should I discard them. It looks like there was a build two hours ago.
1 Like
First let me download the jme3-core JAR and see if the Git hash is correct.
Looks like your current build is still in progress. It will be interesting to see what happens when there are 300+ things to publish on bintray. 
1 Like
Iāll need to discard everything and start over because I accidentally created a release from the master branch.
1 Like
I have BinTray privileges to publish/discard, so Iāll do that myself. Please donāt interfere.
Oh, okā¦ I already discarded the old onesā¦ but I will stay out of it now.
Edit: p.s.: your current build is still in progress so you probably want to wait for that to finish and then discard those before doing anything else.
Things didnāt go well. Somehow the build I created from the master branch got released to BinTray as v3.3.1.
I can tell because the Git hash (which should be 1a05e3f) displays as bb6ac61 when I run apps built from BinTray artifacts. Also there are no v3.3.1 artifacts for jme3-blender or jme3-jogl.
I should probably delete v3.3.1 and release 1a05d3f as v3.3.2.
1 Like
Yes, you already had a build started at 12:30 or so my time that was pushing the master-based releases to bintrayā¦ which I was trying to say in my previous message. I expected you would discard those and try again instead of publishing them.
ā¦but I guess now we will have to delete those. Do you have permission to delete the versions on bintray?
I thought I had deleted all the master-based artifacts before I started the next build.
I believe I have permission to delete versions. However, deleting published artifacts would be a bad thing.
Iām going for a walk to calm down. Back in 1 hour.
If the artifacts are bad then we need to delete them. Weāve done it before. Bad artifacts serve no one and nothing has been announced yet so anyone using them is āat riskā anyway.
Edit: however, I will say this is why versions donāt normally go straight to -stable without at least a release candidate.
Before you push another tagā¦ we really need to remove the 3.3.1-stable release and discard the 16 unpublished artifacts. We need to do this ASAP.
ā¦would have been best to do right after the mistake was discovered. The longer we wait, the more likely it is that you are actually working on 3.3.2.
The 3.3.1 artifacts arenāt so bad, just built (some of them, at least) from the wrong branch of the repo.
Yes, I am working on 3.3.2-stable. Iām doing so because otherwise weāll have two releases with the same name, and that would confuse our users (and perhaps also Engine Leaders like us).
Iāll remove any unpublished artifacts from JCenter before I start the build. Thank you for that reminder.
We shouldnāt try to delete 3.3.1-stable from JCenter, because once something is published to JCenter, unpublishing it will cause problems for our users.
Iāll take care of cleaning up GitHub. I donāt know if what (if anything) should be done about JitPack and GitLab.
Only if they use it.
Itās now a maintenance nightmare because anyone trying to use it will complain about weird things that are unexplainable.
Iām going to delete it because a mistake shouldnāt affect everyone forever when we could have fixed it 10 minutes in instead of 2 hours later.
If you delete it, there will never be a 3.3.1 release.
Iāve already asked to you stop interfering.
Your decision to delete v3.3.0-beta1 last year cost me a dayās work and killed my motivation to work on JME for at least a week.
1 Like