Clearly there is some level where a release is considered poison. What if it deleted a user’s hard drive?
This was a poison release. It somehow included things newer than the next release. Any users using it were going to end up in a weird state of somehow being able to use newer code the 3.3.2. That’s super bad.
In this case, it could have been fixed minutes after noticing it but we left it two hours.
You could easily fix that. But I will leave it up to you.
To me, it’s better to have a dead/non-existent release than a poisoned release. I’d also be fine if you want to build a proper 3.3.1 release.
Edit: and the bottom line, calling what was in bintray “3.3.1-stable” was not the truth.
Once we have a 3.3.0 stable, someone else can continue managing the 3.3 branch and make a future 3.3.1 release whenever they want. It probably won’t be me.
It’s deleted.
That was a judgment call that should’ve be made by the person managing the branch, or with their consent.
I need another cooldown before I resume work on v3.3.2 .
Absolutely not. We cannot have a release that is not what it says it is. I don’t care who is managing the releases. I will not let that person upload a chili recipe and call it a release. Nor will I let them upload a 3.4-prealpha release and call it 3.3.1 stable.
To me the only question was whether to reuse the number or not. The number could not stay because it was lying to users.
note: I also warned you about every one of these problems while there was still time to avoid publishing the release to bintray. I was told to stop meddling… so you published anyway.
The meddling I objected to was not the warnings, but deleting things from the server—unpublished packages, at the time.
Despite your warning, I made a mistake or two. I’m human. I discovered my mistakes quickly, and promptly/publicly took responsibility for them. There was disagreement about how best to proceed. I held off so that discussion could occur. Action was taken without my consent.
What’s done is done. I still believe I can manage this release, provided I have authority to match my responsibilities.
Do I still have the community’s support for managing dot-dot releases from the v3.3 branch? As I see it, there’s no urgency. I’ll give you all 24 hours to think/discuss.
Next time I will shout this louder in giant red letters… the “between the lines” message here was “stop what you are doing, do not publish”. Like, 30 minutes later or something they were published anyway.
Within the constraints of not leaving mislabeled releases up on public repos, yes, you still have the authority from my perspective.
I don’t see a reason to question this - technical issues with releases happen all the time, and it’s fixed now. No harm, no foul, and the job needs someone (like you) who has experience managing the releases.
In this instance, shouting louder wouldn’t have helped.
I read and understood that message, and tried to follow that advice. Unfortunately, I got confused about the status of the various builds. (The fact that an unknown number of files had already been deleted probably contributed to my confusion.) When I clicked on the Publish button, I believed all the builds were complete and all the unwanted files had been discarded.
Maybe you were right this time. But sometimes the harm done attempting to cover up a mistake exceeds the harm of letting it be.
How shall we make such decisions in the future? Unilaterally, or as a team?
If you’re not sure, just ask. If nobody knows, lead the way.
Sometimes I just ask anyway for confirmation, even though I didn’t feel I needed to, and came out of the conversation all the wiser.
Just make good use of the team. We’re there to teach and learn from each other. Sometimes we’re right. Sometimes we’re wrong. But I’d consider it a disservice to myself if I were so headstrong as to pretend I knew it all and ignore the company of a valuable team.
I need you just as you need me. And together we achieve great things.
For what it’s worth, I only discarded the 10:30 AM release (my time) and only because I thought you couldn’t. I didn’t touch anything after that. Nothing from the 12:30 release (my time) had been uploaded yet.
Edit: also, I know you stay off discord but there is a “github builds” channel there that is useful during releases. It shows when the things are actually deployed and stuff. I haven’t looked at the github actions status during a release so I don’t know if it’s as convenient as that.
Actually, I often lurk on Discord—though as you’ve noticed, I generally avoid its discussions.
I was aware of the “github-builds” channel there. Unfortunately, I wasn’t familiar enough with it to recognize a build in progress. I agree it looks useful—definitely superior to browsing commits at GitHub and clicking on orange discs (which had been my process until now).
Moving on, I’d like to discuss the name of the next release. After what happened, I plan to skip “3.3.1”, so I was thinking “3.3.2-stable”.
Where did this tradition of tacking “-stable” onto JME release names come from? It appears to have started with “3.1.0-stable”, which never got a dot-dot (patch) release. Nehon tacked “-stable” onto the 3.2.1 release, and I followed suit for 3.2.2 through 3.2.4 .
In Semantic Versioning 2.0, however, a hyphen after the patch number indicates a pre-release version of that patch. So some users may find vanilla “3.3.2” more reassuring than “3.3.2-stable”.
Meanwhile, Paul expressed concern about going straight to -stable without a release candidate. After the testing that’s been done in the past week by @remy_vd, myself, and others, I’m confident the patch release (by whatever name) will be good, but if anyone thinks a “-beta” release is warranted, now’s the time to say so.
-stable indicates that it’s ready for use in a way that sorts after -alpha and -beta in tools that do not specifically parse things after the - and apply semantic meaning to them.
Yes, we should continue to use -stable when we mean “this is the release you should actually use”.
Some apache projects even treat point releases as throw-away numbers. .0, .1, .2, .3, etc. might all be alpha and beta releases and finally they’ll label one -stable.
I’m ok with skipping it since it was visible for a couple hours… I’m also ok with reusing it because it is extremely unlikely anyone actually downloaded it during that time.
This part is up to the person doing the point releases. The part I critically objected to was leaving a mislabeled release up. That eventually leads to version labels being meaningless to users.
