Versioning

[tacit cloak]

eh it's not gonna happen

[wooden sage]

Well, no, because it's not legacy forge. It would provide a forge mod with those version numbers, but it would need its own versioning too

[tacit cloak]

and if it does, it can be called neo-legacy and use its own versioning scheme

[wooden sage]

I'd say just go with MC version based stuff to call it a day

That way you get to not step on forge versioning, and this also isn't an issue

[delicate panther]

right

this is stupid

[wooden sage]

Or that, yeah

[delicate panther]

how exactly would it do this?

you seem to think that tech somehow magically exists

[unreal minnow]

Howdy

[boreal blade]

Honestly, I don't really think that we really NEED to backport, so I'd be fine with keeping the current forge versioning scheme but restarting numbering at 1 (or honestly, even continuing where we are is fine)

[tacit cloak]

@Mod("forge") class BackwardCompat {}

[[mods]]
modId="forge"
version="newest compatible"

[unreal minnow]

NF-0.0.0-EXP/STABLE/RC

[tacit cloak]

but eh

[wooden sage]

...have it JiJ an empty mod with the forge mod ID and the given version?

[tacit cloak]

discussing old version maybes is bikeshedding

[delicate panther]

this entire channel is bikeshedding

[boreal blade]

Like, the current forge versioning scheme, for all the issues it has, works and is well-known

And if somebody wants to build neo for 1.12 for example, they'd probably need to basically maintain a whole fork of neo which would probably justify an even more differenter mod id

[balmy ore]

okay, giga, let's try an easier vote maybe? just to try to arrive at some sort of conclusion here:
Restart at v1 or continue from v48?

[boreal blade]

And since old minecraft versions are unchanging, they could easily use whatever versioning scheme they want without having to worry about minecraft changing

[balmy ore]

no need to be recirculating more arguments

imo

[delicate panther]

gimme a minute

[unreal minnow]

👀

[delicate panther]

even trying to construct a vote is just farcical

😦

there's a four dimensional matrix, plus extra

we have fallen for the trap of being so open minded our brains have fallen out

[tropic wave]

when you need quaternions to figure out who won it gets a bit chunky

[boreal blade]

i'm okay with limiting the vote to forgever or forgever + restart, since i've already accepted that there are good reasons why my ideal versioning scheme would not work, especially at scale

[balmy ore]

^ that's what I feel

it's not my ideal versioning system, but it'll be fine

[analog badge]

cpw remember the subproject leader stuff? maybe name someone as 1.20.2 release manager and let them decide 😛

[delicate panther]

well, orion is. but this is a project wide long term effect thing

what is forgever?

[boreal blade]

forgever being the current scheme used by forge

[long ingot]

I know the version scheme I would pick

[delicate panther]

why do you believe we need a "perfect" version scheme

[long ingot]

It would be the existing

With a special suffix for snapshots

And that is it

[analog badge]

Cool

[tropic wave]

okay, good, problem solved

[delicate panther]

what does that mean orion?

[long ingot]

48.0.0

[analog badge]

Restart at 1 major or keep going?

[long ingot]

Would be the next

[delicate panther]

no commoble?

[long ingot]

And once the snapshots for 1.20.3 / 1.21 start, it would be 49.0.0-alpha.<buildnumber>

It covers all bases

The format is easy to understand compatible with all existing versioning schemes, maven and gradle

[tropic wave]

what if we use a different modid for snapshots

[slate rivet]

I'd personally suggest different artifact for snapshots but apart from that I'd agree with Orion

[long ingot]

It is not needed cat

[delicate panther]

neofroge?

ugh

[long ingot]

Gradle takes care of preventing you from using the version

[delicate panther]

right. here's the plan

we need to decide

voice chat, at the top of the hour

so in 45 minutes from now

[long ingot]

And removing the custom artifact, takes care of so many other side effects

Okey

I will be on the move

But I can make that work from the car

[slate rivet]

feel like it should be separated out but honestly, it doesn't actually matter to me
So long as it works well enough for what we need, it's all thats necessary

If it's easier (toolchain wise) to stick to single artifact then go for that

[remote apex]

maybe push it one more hour? just so we can get more maintainers to possibly join?

[long ingot]

Much easier!

Much Much easier

[delicate panther]

the amount of work to do froge was insane. we still have code smell from trying to implement it

[long ingot]

Yep

Code small I am highly considering removing

But have not

[slate rivet]

I see, then yes just add a suffix, we might need to make a post about how your should do maven ranges (because of the fact -alpha is a pita using the current ranges we suggested) but thats not a huge issue

[long ingot]

it is actually really simple

If you just want the current MC version you pin it to the specific one

So 48.0.+ works

And 48.+ also does

If you need a guarantee that snapshots are excluded

Something like

[slate rivet]

something like [47.0.0,48.0.0-alpha) iirc?

[long ingot]

[48,49.0.0-alpha) is exactly what you are looking for

Yes cat

[delicate panther]

so ugly

[long ingot]

that is exactly the correct version

[remote apex]

maven is ugly

[long ingot]

The plus should also work cpw

At least on gradle

Does not work in maven

But that is wht we have in the FML system

[delicate panther]

no one is using maven to build mods

[long ingot]

FMl uses Maven formatting

[delicate panther]

yes

[slate rivet]

We use it for dep info in the toml

[delicate panther]

and plus is a valid separator

i wrote it 😛

[long ingot]

I know

Just wanted to point out, that unless you want to specialy create code for dealing with calver, ordering and sorting of snapshots, then sticking to maven formats, regardless of how ugly they are, is the simplest, given that they are basically compatible with all the shit that is rolling up our hill

But we can talk about this in an hour

Or two

I first need to deploy an update to GDI

To make my Buildscript cleaner

[delicate panther]

let's wait to 11am my time, so in 100 minutes from now.

because maty wants to

[long ingot]

Okey

I can work around that perfectly

Does not matter

[delicate panther]

hopefully you'll be home by then

[long ingot]

I will be on the road / on my way home probably

[delicate panther]

k

[long ingot]

But that does not matter

[delicate panther]

hmmm

[unreal minnow]

NeoSnapForge-48.0.0?

[stoic sedge]

Won’t know till we try

[boreal blade]

at this point we should rename #1105595318197825557 to #bikeshedding

[stoic sedge]

24 hour votes for maintainers and sc. majority wins. If tie, default versioning ends up used

[delicate panther]

nah

[boreal blade]

i feel that, at the very least, keeping the status-quo with versions doesn't harm us

[delicate panther]

24 hours is far too long

[stoic sedge]

2 hours then

[delicate panther]

and this conversation has already taken days

decision at the voice chat

[long ingot]

Yep yep yep

[slate rivet]

I can't be part of that, don't have audio, but I'd vote whatever way we need to gets this ship moving

[remote apex]

also <@&1128776937410670663> voice meeting in 1h30mins fyi 😛

@delicate panther can you deny the permission "mention everyone when stage starts" for everyone (moderators included) in #1129163369874735204

[long ingot]

seems to be set

Not sure if Cpw did it

or it already was that way

[delicate panther]

i just set it on everything

[remote apex]

good

just made sure we won't ping everyone again in 1 hour..

flashbacks

[unreal minnow]

that went by fast damn

[strong stag]

Give me notes at work

[delicate panther]

not really notes illy. it's time to decide something.

[boreal blade]

i vote for the good one, y'know, the one that's good

😜

[remote apex]

<@&1128776937410670663> booop

[long ingot]

Yes

I need one minute

Phone is connecting to the car

[remote apex]

you have 30 seconds /s

[delicate panther]

if you have ANY interest in versioning, get in the meeting channel now

[supple panther]

have fun storming the castle debating versioning

[delicate panther]

@boreal blade you had an opinion, now is the time

[boreal blade]

I'm currently in a meeting at work

[paper aspen]

so long as the versioning works I don't care

[boreal blade]

but yeah my opinion at this point is forgever (i.e. the current scheme) while restarting numbering at 1 because it's a known quantity

[supple panther]

yeah, I have also said my piece. if the versioning works, great. I will probably find something to complain about with it regardless

So ultimately I agree, just make a decision

[wooden sage]

I cannot join voice - if there is one piece that I have a strong opinion on, it's that you shouldn't use the middle digit like in the current system to show BC-window-ness

[stoic sedge]

Can’t join voice but I’m fine with any versioning scheme. But breaking changes should be allowed in 1.20.2. A lot of people assumed or was told that 1.20.2 is when Neo does breaking changes from forge so registry rework PRs and caps pr and other improvements should be allowed. Modpack makers already settled on 1.20.1 as established so 1.20.2 makes a good transition period for breaking changes to lead to 1.21

[rapid totem]

i'd echo that sentiment
my assumption was that the plan all along was to pull those big changes -- at least, the registry rework -- for 1.20.2

[stoic sedge]

We don’t need to rush a stable build out anyway. A stable 1.20.2 won’t change or benefit anyone. Launchers don’t care if it is “stable” or not. They will still add support

[visual locust]

also, in the main menu: I think the bottom-right text should only notify if a new stable version is out imo

[delicate panther]

mcminor.mcpatch.build

unstable builds are published into a snapshot repo with mcminor.mcpatch.number-snapshot

two maven repositories:

stable or release repository: mcminor.mcpatch.N

unstable: mcminor.mcpatch.N.M-SNAPSHOT snapshot builds

designated compatible unstable builds will be promoted either by copying or rebuilding, into the stable repository where they'll get their new number

an implicit break everything window exists whenever a MC version release.

there may be explicit additional breaking windows where stable will not be further compatible backwards. there are no plans for this at present.

20.2.1 - future stable MC 20.2 release build.

additional, compatible builds will be numbers 20.2.2 and such.

N starts at zero in unstable

20.2.0.1-SNAPSHOT -> 20.2.0.2-SNAPSHOT

promotion will promote 20.2.0.2-SNAPSHOT to 20.2.1

snapshot resets to 20.2.1.1-SNAPSHOT

[lapis bolt]

Is there any particular reason why it has to be two repos? That seems really annoying to support for launchers

[delicate panther]

ok.

revised

mcminor.mcpatch.B-SNAPSHOT - unstable artifact.

[boreal blade]

suggestion: the snapshot repo should also include the release builds, that way it can be the one you recommend modders use (so they can target snapshot builds for porting to new mc versions) and then the stable repo can be the one you recommend users use

[delicate panther]

mcminor.mcpatch.B - stable artifact

they may be in the same or separate repos

that's a research item

[boreal blade]

that way launcher support is basically a checkbox "include unstable versions" which swaps the repo to search for versions through

[delicate panther]

yes

[wooden sage]

Wait, does this mean that once a new snapshot is published other older "unstable" snapshots will be overwritten?

[wooden sage]

Or am I misinterpreting this?

[delicate panther]

B is a build index. so it's continuously incrementing

[wooden sage]

Ah, okay

I'll point out that you shouldn't use -SNAPSHOT then

That gets special treatment by maven

[delicate panther]

the B for a snapshot will become the stable B. so we could easily have 20.2.100 and then 20.2.500 in the "stable" world

[wooden sage]

Including constant update checks and whatnot

[delicate panther]

are you in the voice?

we want that

[wooden sage]

If you're not overwriting old builds why do you want that?

[sleek tinsel]

^

[delicate panther]

snpashots don't overwrite anyway?

there's a hidden number

[wooden sage]

SNAPSHOT is meant exclusively for when you are overwriting

[stoic sedge]

Not everyone is in voice. I’m technically in a conference at work lol

[wooden sage]

And by overwriting I mean incrementing that hidden number, sure

But if you're not doing that SNAPSHOT brings a lot of cost with no benefits

And so I'd use beta, or unstable, or whatever else instead. Basically anything really

[delicate panther]

-unstable

[sleek tinsel]

Snapshots will overwrite if their prefix is identical

[boreal blade]

-mcsnapshot would work too if it's for a minecraft snapshot

[lapis bolt]

Also, what constitutes an unstable version? Does any PR land in an unstable build first and gets promoted to stable at some random point (basically status quo with recommended builds) or only within the breaking phase? If the former, then that's basically the death of quick innovation for mods since modpacks will nope out on stuff marked unstable

[sleek tinsel]

Using snapshots in any way makes mods unable to target a specific version of an unstable build. Which is just headache for no benefit, i don't want Forge randomly updating between working locally and jenkins building.

[delicate panther]

everything is unstable

always

promotion is a manual process for an existing unstable build, that strips the suffix

and republishes

[wooden sage]

I assume this will happen fairly often outside of an BC window?

[strong stag]

-bleeding /s

[quiet jewel]

Personally, a system like this that prevents PRs from reaching the "main" version lineage quickly just disincentivizes me to make any contributions to the upstream project. There should be less friction in the PR process, IMO, not more

[stoic sedge]

I miss status quo versioning already lol

[lapis bolt]

Yeah, that's basically what my comment above boils down to

[delicate panther]

we've backed down from snapshots

looking for one that has the special sort behaviour

[wooden sage]

I think the proposed system could work fine if there were a time - outside of the BC window - where promotion is automatic

[boreal blade]

so 20.1.20230920 could be a valid version, where 20.1.20230920-alpha would be the indev version?

[long ingot]

This has been discissed

And our aim is to get your PRs quickly into the main branch and published as unstable

[boreal blade]

(i'm using 20230920 as a build number here, it can be whatever increasing number you want)

[long ingot]

And then tested

And promoted to stable

As long as they are not binary breaking

[quiet jewel]

Right, but if the community is using stable, that means my PR isn't usable widely till it hits stable

[mossy flume]

if what you want is maintainer controlled versioning, this is perhaps the most convoluted way to make it happen

[delicate panther]

https://github.com/apache/maven/blob/1eae6684e3760d2a2e311c3eeaa166adbe99b69f/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L317

[quiet jewel]

whereas if I mixin the same fix, it's usable immediately

[delicate panther]

i vote for -milestone

[wooden sage]

Yeah, that's my big worry here. I'm going to target what users will be using, and if I PR something it's so that I can use it

[boreal blade]

re: -rc, i would suggest reserving that for doing some sort of big integration test (like pushing to forgecraft for example)

[long ingot]

The problem is that this behaviour has not changed

Like this gets to the general public immediatly on build

[wooden sage]

I think the easiest solution is to automatically promote builds made outside of a BC window

[long ingot]

Just not in a recommended build

So I am not sure what the problem is embeddedt

[quiet jewel]

That's only true if the general public is using unstable

[wooden sage]

Yes and currently we have to constantly tell people to use latest not recommended. Calling latest "unstable" makes that even worse...

[long ingot]

True, but the general public is not using none-recommended builds currently anyway

[mossy flume]

the unstable moniker will imply that it's not to be used

[remote apex]

it is?!

[wooden sage]

The general public is using latest currently

[remote apex]

modpacks are updating to latest forge after an RB because it's.. stable?

[lapis bolt]

The problem is the wording. Latest vs. recommended is one thing but stable vs. unstable is substantially worse

[wooden sage]

I'd know, because I consistently depend on latest

[stoic sedge]

Latest is greatest and should be the gold standard tbh

[strong stag]

we could just call it a recommend build instead of stable

[quiet jewel]

Obviously some PRs should be held back, but simple stuff should not

[rose halo]

PRs sometimes have to sit. it's all situational and generalizing it is not a good idea

[ashen heart]

I second that (alternative: beta)

[remote apex]

if unstable can have breaking changes until the next stable version no one is going to use unstable

[wooden sage]

Basically - given that that rolling release is what we should be encouraging use of, we should name it accordingly

[delicate panther]

how are we supposed to resolve this conflict

[quiet jewel]

don't require every PR to go through unstable first

[delicate panther]

that we can't break "stable" but we have to merge to stable

HOW?

[quiet jewel]

not every PR is a breaking change

[paper aspen]

which will just amplify the previous feeling lots of the community had of PRs sitting forever

[delicate panther]

how do we know?

[quiet jewel]

take my chunk future fix as an example

[remote apex]

if you want to test PRs then publish PRs separately

[long ingot]

We do not know if your PR is a breaking change or not.......

[delicate panther]

do you always know?

[wooden sage]

You just... Don't break stable? And merge breaking changes at the next MC version. "Which things break" is resolved by a best-effort system, publishing PRs, and reverting if absolutely necessary

[delicate panther]

what happens if you're wrong?

[long ingot]

The past has shown that more often then not, if it is not a bugfix, it was breaking in some way or another

[mossy flume]

wut

that's absolutely not true

[quiet jewel]

then fix them?

[delicate panther]

if it was more complex than a bugfix, there was a facet that caused potential breaks, probably

[quiet jewel]

it's software dev. we create bugs 😛

[delicate panther]

then what's the point of stable?

[merry cosmos]

how much testing is gonna be going on if nobody is using it

[wooden sage]

That it's post the window of intentionally merging BCs

[delicate panther]

do we just abandon any notion of stability?

[wooden sage]

That's the important bit here

[rose halo]

If PRs can go just go straight in then you have to figure out what qualifies as going into unstable and what doesn't, and in that case you start a whole bikeshedding scenario about whether a pr should go in immediately or not

there's pros to PRs going in but cons to the management

[quiet jewel]

unstable is a nice spot to land things like rewriting half of the caps system

[boreal blade]

so, if i'm understanding the current consensus:

• 20.1.20230920 is the stable version that users will download from the main repo
• 20.1.20230920-(alpha|milestone|whatever) is the next in-development version from the development repo
• when the next in-development version is deemed stable, you strip the -alpha and push it to the main repo

[wooden sage]

"stable" means "if we break shit we'll fix it"

[quiet jewel]

it's not a nice spot to land trivial changes like a new event, or a bugfix

[late kraken]

agreed

[mossy flume]

stability is important, preventing new features from reaching stability because things merged before it were breaking is important to avoid

[stoic sedge]

What if the bug fix causes a bug? Throw out your system and treat every version as a breaking change?

It’s not a slippery slope basically. Reasonable assumptions can be made about PRs if properly triaged and tested

[merry cosmos]

what was wrong with latest and recommended?

[wooden sage]

This doesn't work for the reason XFactHD and embeddedt described

End users should be using what you're calling "unstable"/whatever there

[merry cosmos]

yes lets start using windows versioning terms

[wooden sage]

End users should be using latest

[stoic sedge]

Recommended promoted people to it instead of latest. Recommended should’ve been called “non-breaking” and latest promoted

[rose halo]

IIRC SP stands for "Stable Production" and it follows after RC, basically the version that's ready to go into stable as-is

[wooden sage]

Why not just make everything after the first recommended build also a recommended build? So, a "non recommended build" just means "we're in a BC window" and that's all it tells you

Seems like that would fix this issue

Given that users need to download latest anyways

[stoic sedge]

Question, do we even need a stable/recommended build if everyone should and does use latest always?

[wooden sage]

Because, well, modders are using latest

[boreal blade]

i found some useful docs on the -suffixes

[long ingot]

Yes, because players/modpack makers want it

[mossy flume]

my honest opinion is that there should be a stable cycle - after a certain version, ALL builds are stable, until we cycle back around to breaking. Otherwise we're going to end up in a situation where we started pushing reworks and breaking changes to an -unstable artifact, and we're unable to push non-breaking fixes and features to the last stable, because there's a breaking change in the middle

[delicate panther]

that means that all dev on neo stops as soon as an RB happens

[wooden sage]

Good point. I think we should be expressing the end of the BC window somehow but that's about it

[wooden sage]

...why? Wut?

[mossy flume]

that's not true.. wut?

[remote apex]

modpacks want a latest version that has no breaking changes. a latest version that all mods would work for

[delicate panther]

until next MC release?

[quiet jewel]

only breaking dev

[delicate panther]

so just bug fixes

[mossy flume]

?

[stoic sedge]

You can add new events without breaking stuff

[remote apex]

they don't need nor want a chain of versions that change stuff every time and can break at any time

[wooden sage]

No...? It just means that if BCs happen by accident, you revert them...?

[mossy flume]

we can add new features and rework existing features without breaking

very easily

[paper aspen]

do they though? Or is it just because they don't understand the terms they ask a lot what they should use? Because modpacks have to use the latest version or at least not RB because mods often times need features from past the RB as the modder PRd said change into the loader and wants to make use of it

[lapis bolt]

That has never been the case. People have always found ways to introduce tons of features and fixes without breaking anything

[merry cosmos]

my understanding is that the way recommended and latest worked on forge was that recommended was updated every once in a while to a newer version after it hardened

[wooden sage]

"not a BC window" just means no intentional BCs and you revert them if they happen

And do your best not to merge them to begin with

Modpacks already tend to use latest, not recommended. So do users

[boreal blade]

ALSO maven accepts semver 1.0.0 and sorts them according to those rules

[delicate panther]

and yet, look at brainstorming. that's technical debt accrued by forge NOT being able to change shit for YEARS

[wooden sage]

So frankly, that argument is useless

[remote apex]

it was able to change shit for years, what are you arguing cpw?

[mossy flume]

we could still change those things immediately after a new version, we just weren't allowed to

[remote apex]

it has changed?

but some changes haven't been wanted to some people?

[paper aspen]

just means on MC version change have a larger BC window

[delicate panther]

if that was true, why is there so much that needs changing?

[mossy flume]

the problem wasn't our versioning, it was leadership

[stoic sedge]

Remove the tech debt next Mc version?

[wooden sage]

So, it's no different than your staging system? You can't merge intentional breaking changes outside of a BC window there either

I'm just saying get rid of the idea of a "stable" version

Given that everyone uses latest to begin with

[lapis bolt]

A lot of those things were not reworked properly or at all because people with veto power blocked them and NOT because of non-breaking phases

[wooden sage]

And given that everyone should use latest

[remote apex]

there have been continuous PRs reworking systems during different BC windows that were more or less ready if it weren't for someone blanket banning specific changes or people

[boreal blade]

so according to this, 20.1.20230920-dev SHOULD BE A VALID VERISON that maven treats as a prerelease version

[delicate panther]

the problem with abandoning stable - modpacks really need a stable version to target.

[quiet jewel]

which makes sense (responding to Orion's comment in voice)

[wooden sage]

Anyways, I have to head out - I'll just say that If you start calling latest something that implies to users that they shouldn't use it... Nobody is going to want to PR stuff, myself included. Currently, users use latest. They should use latest. In fact, to use many mods they have to

[merry cosmos]

@long ingot define versions A and B i want to make sure i dont misunderstand what ur saying

[wooden sage]

Modpacks can't use a RB for that anyways because mods very often need stuff newer than it

[delicate panther]

doesn't -latest also work as a suffix @boreal blade

[stoic sedge]

Neo page could state when a Mc version is “ready for users” when we get a build up we feel is solid for widespread consumption

[paper aspen]

they don't get one?

[boreal blade]

according to https://maven.apache.org/pom.html#version-order-specification
If version strings are syntactically correct Semantic Versioning 1.0.0 version numbers, then in almost all cases version comparison follows the precedence rules outlined in that specification.

[paper aspen]

because modpacks want to use latest version of mods to have bugfixes

and mods require newer versions than last "stable" for feature reasons

[remote apex]

modpacks want to use something that doesn't change randomly

[wooden sage]

Yeah, that. Newer versions have features that mods need, and have bug fixes for forge itself

[remote apex]

they don't want new features to not happen

they just want them to not break the entire pack

[wooden sage]

As long as neo isn't intentionally introducing breaking changes, you're fine

[stoic sedge]

Marking the entire Mc version as ready for users and provide latest download front and center gets people to latest always and let them know to use it

[boreal blade]

oh? i figured that the maven POM was how the versioning worked, mb

[delicate panther]

we're not going to deliberately introduce breaking

but they definitely happen

[mossy flume]

they happen accidentally, sure. that's when we make an announcement, apologise, and fix it, then move on

[stoic sedge]

Revert the breaking change. Easy revert for a pr

[wooden sage]

Yes, they do. Cpw, my point is that people use latest already

[delicate panther]

that's literally the point of what we were doing

[wooden sage]

Because they have to

[delicate panther]

@stoic sedge

[wooden sage]

Yes but which version are you recommending for general users?

[delicate panther]

whatever build has been blessed as "stable"

[remote apex]

what are you defaulting to?

[woeful sphinx]

Maven versioning: 1.0.0-blah > 1.0.0

[wooden sage]

It better be that "latest" one otherwise it's mod devs that have to deal with telling people "it's stable enough"

[wooden sage]

Yeah, that's where I take issue

That build is out of date

[woeful sphinx]

Maven versioning: 1.0.0-alpha < 1.0.0

Maven versioning: 1.0-alpha < 1.0

[wooden sage]

Often by a long time

[woeful sphinx]

Maven versioning: 1.0-milestone < 1.0

Maven versioning: 1.0.0-beta < 1.0.0

[wooden sage]

Mod devs, users, and modpack makers should, and currently almost always do, target latest

[woeful sphinx]

Maven versioning: 1.0-m1 < 1.0

[paper aspen]

but most of the time when that does happen the only reason it gets caught is from the mass number of users who do different things in the game and then have at least a few happen to run into it. So like even just keeping it on a separate branch for a bit won't necessarily have them get caught either

[boreal blade]

according to the link I found earlier a, b and m also works

yeah

the "alpha", "beta" and "milestone" qualifiers can respectively be shortened to "a", "b" and "m" when directly followed by a number.

[woeful sphinx]

Maven versioning: 1.0.0-rctest > 1.0.0

Maven versioning: 1.0-ms > 1.0

Maven versioning: 1.0.0-sp > 1.0.0

Maven versioning: 1.0.0-alpha < 1.0-latest

[boreal blade]

at that point just have mcminor.mcpatch-SNAPSHOT?

[sleek tinsel]

@long ingot please no.. no docker latest tag..

[wooden sage]

Can't target specific versions with that

[sleek tinsel]

See my comments above about targeting a specific version

[woeful sphinx]

Maven versioning: 1.0-release == 1.0

[boreal blade]

orion's suggesting a x-latest for people who want the latest

[rose halo]

ok apparently maven just doesn't support sp at all

[woeful sphinx]

Maven versioning: 1.0-rc < 1.0

[boreal blade]

alpha = a <<<beta>> = b <<<milestone>> = m <<<rc>> = cr <<<snapshot>> '<<<>>' = final = ga = release < sp

[woeful sphinx]

Maven versioning: 1.0-cr < 1.0

[boreal blade]

"alpha" < "beta" < "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"

candidate release?

[rose halo]

omg... cr is Candidate Release and rc is Release Candidate. they literally flipped it

[boreal blade]

The usage of 'CR' qualifier is discouraged. Use 'RC' instead.
The usage of 'final', 'ga', and 'release' qualifiers is discouraged. Use no qualifier instead.
The usage of 'SP' qualifier is discouraged. Increment the patch version instead.

Prefer 'alpha', 'beta', and 'milestone' qualifiers over 'ea' and 'preview'.
Prefer '1.0.0-RC1'' over '1.0.0.RC1'.

[rose halo]

okay, strange then, because from what i know sp comes right after rc but before release

[delicate panther]

anyway

[boreal blade]

sp is service pack, think like windows xp service pack 2

[delicate panther]

mcminor.mcpatch.N-cr - continuous releases and mcminor.mcpatch.N - promoted releases

[quiet jewel]

I'm still not convinced unstable (replace with any alternative word) is needed

[rose halo]

service pack or stable production? i've heard both now

[keen yarrow]

bleeding edge instead of unstable?

[rose halo]

although service pack does make sense in this case if it's after release

[lapis bolt]

Agreed. Since the only ones updating to unstable NF builds are modders who prepare their implementation of the newly introduced thing, the amount of people testing such a version is very low since modders don't change their target version for fun, they only do so when they have an actual reason.

One accidental breaking change I want to mention as an example and one I myself introduced was making the experimental light pipeline default to enabled. Absolutely nobody would have caught that in an unstable build since modders wouldn't update to such a version since they would just expect the change to be transparent to them. In other words, the change would have lingered around until promotion to stable instead of for merely 5 hours or so because only players would have caught the issue when updating packs to that version

[boreal blade]

okay, so:

• 20.1.20230920 is the stable version that users will download from the main repo
• 20.1.20230920-cr is the next in-development version from the development repo
• when the next in-development version is deemed stable, you strip the -cr and push it to the main repo

(20230920 is just any increasing number per build, i chose date to make it obvious)

[delicate panther]

the -cr suffix sorts before it's "no suffix" equivalent, so we can publish "promoted" releases without the suffix and they'll be preferred.

[quiet jewel]

right but I'm really not convinced manual promotion is the way to go

[remote apex]

because it's not#

and arguing over how to call it is not fixing anything

it's ignorant

[boreal blade]

calver for the patch is just a convenient monotonic number for the build number, most CI systems use that 😅

[delicate panther]

manual promotion is entirely optional with this scheme

we may decide we need to do it for modpacks or whatever.

and that will be done by removing the -cr suffix

[paper aspen]

well also often times the breaking changes are from random side effects that the modder probably isn't testing for as well they didn't think to test that scenario in the PR for whatever the use case is.

Not to mention while modders do update to latest most only update their in dev when they actually need/want new features/a specific bugfix so then that is an even smaller subset for who may run into a breaking change

[remote apex]

so you can still have breaking changes while the -cr suffix is there?

[mossy flume]

having a copy of every release seems very inefficient if we're not going to use it (and indeed, if using it is counterproductive in the first place..)

[delicate panther]

the CR just means it's Continuously Released

[boreal blade]

i think curle's reading what i'm posting which might suggest that

[delicate panther]

we won't be copying every release. only potentially nominated ones we feel deserve promotion

[lapis bolt]

Yeah, the example I mentioned was a side-effect nobody tested for. Your second point is exactly what I wanted to get across

[mossy flume]

which, after the first stable release, should be every build, lest we make a breaking change in development and then never be able to push a stable again

[quiet jewel]

once we copy every build, the unstable branch may as well not exist

[mossy flume]

if we 20.2.1 stable, then 20.1.2-cr has a breaking change (say, caps rework), we can't push a bugfix to stable, because now dev has a breaking change

we're locked to no further development because of this system

[delicate panther]

no?

[quiet jewel]

it would have to be cherrypicked into stable

[mossy flume]

which means diverging history

[quiet jewel]

yes

[delicate panther]

branch the diverge point

[quiet jewel]

to be fair that's basically how all LTS projects work

[delicate panther]

this is literally standard practice

[remote apex]

just ask modmuss about his experience doing that

for every fabric release

[quiet jewel]

exactly

[delicate panther]

cherrypicking is NOT what we're advocating, if we NEED to push a stable fix

[quiet jewel]

how else do you do it though

[delicate panther]

you generally don't cherrypick into the branch from unstable for a bugfix, unless the bugfix also exists there

typically it doesn't tho

[mossy flume]

on a most basic level, once we've published a stable release for a version, we can't push a new stable with breaking changes - so it makes more sense to branch off a development branch from stable to make those reworks, ready for the next breaking change period at the start of the next MC version

... wait, that's the current system.

[boreal blade]

ugh, at my last job we had to cherry pick all the time to get fixes into different branches because they insisted on having branches for each release

it was pain

[delicate panther]

myself and orion are using the system we have discussed

i think we have to make a choice, and make it now

and so we have agreed on this as the decision. sorry @mossy flume

[mossy flume]

i think you've made a huge mistake.

this versioning scheme doesn't work with the concept of what we do.

[paper aspen]

but the system you have discussed is basically unusable from a moddev perspective

[boreal blade]

I'm personally fine with using mcminor.mcpatch.N-cr for CI builds and mcminor.mcpatch.N for stable builds

[delicate panther]

i don't think we've made any significant changes.

[lapis bolt]

Using it for what? Unlikely to be a modloader or similar thing that requires quick innovation while staying a stable target for API consumers

[quiet jewel]

that's simply not true

[delicate panther]

i have no idea what you're talking about xfact.

[long ingot]

You can't have both!

[mossy flume]

we can, and we have for many years

[long ingot]

No we did not

[mossy flume]

?

[long ingot]

That is a complete illusion

We had many many many reversion, bugfixes with behavioural changes and even breaking changes after RBs

[delicate panther]

the version number will be mcminor.mcpatch.N-cr and potentially mcminor.mcpatch.N for "promoted" releases

[quiet jewel]

That doesn't make the product unstable

[mossy flume]

ah yes, my hard work for the last 4 years has just been an illusion. screw my contributions and team management making sure THIS EXACT THING doesn't need to happen

[quiet jewel]

because the final version was still binary compatible with the original

[mossy flume]

thanks for that Orion

[delicate panther]

wut?

what are you even talking about.

[native flame]

Someone should executive decision to keep the current system and halt this fiesta™️

[lapis bolt]

The amount of reversions I can remember over the last few years can be counted on one fucking hand

[remote apex]

the executive decision that was made was to change to what everyone else disagrees with

[quiet jewel]

that seems like a contradiction for an open-source project ngl

[graceful rover]

shadows, no idea if you are in the meeting, the 2 making the executive decision, don't agree with us

[quiet jewel]

Sure. Were all of those fixed?

[sleek tinsel]

@long ingot didnt all those features land during breaking windows?

[paper aspen]

and the other cases tended to be pretty quick merges in ways that just fixed whatever corresponding bug/break ocurred

[lapis bolt]

Exactly

[rapid totem]

"bugfix with behavioral changes" apply to nearly all categories of bug fixes, because the premise of a bugfix is fixing (ergo changing) buggy behavior into acceptable behavior

[quiet jewel]

^

[stoic sedge]

Anyway, if this is the scheme this is going out, well, we will see what happens. I feel a lot of people will back out of making PRs and stuff

[delicate panther]

that is literally not what we're deciding about

[stoic sedge]

Probably me too

[quiet jewel]

Yup. Will be way faster to keep fixing things the way I always have

[delicate panther]

i have no idea what you think we've decided

[quiet jewel]

you've decided on a stable/unstable branch (naming can change), right?

[rapid totem]

for reversions, the only one that I can recall at the moment was the reversion for the DFU set of PRs iirc

[delicate panther]

we've decided: mcminor.mcpatch.N-cr

that's it

[lapis bolt]

Yeah, the DFU ones and the light pipeline default setting

[wooden sage]

...so, which version do you recommend end users use?

[quiet jewel]

can PRs be merged to stable directly?

[boreal blade]

the latest mcminor.mcpatch.N

[wooden sage]

If whichever version you recommend end users use isn't the cr version... That's an issue

[quiet jewel]

that is important

[delicate panther]

the two decisions are: we've added -cr to identify "continuously released" builds. and we've embedded the mc minor (20) and mcpatch (2) as the first two numbers. The third is an incrementing number.

[quiet jewel]

not really, if you merge them to unstable first, there is a delay

if you merge to stable, that is the same as the status quo

that is objectively incorrect

[boreal blade]

mcminor.mcpatch.N-cr is basically a "hot off the press CI build"

[delicate panther]

there's always a delay between "released" and "promoted"

[wooden sage]

When do continuously released builds get promoted to normal builds? (Outside of a BC window I mean)

[delicate panther]

yup monica

[gentle elbow]

people use non latest forge ever?

[sleek tinsel]

What the fuck orion?

[delicate panther]

all the time unix

[rose halo]

the takeaway from this whole conversation is that versioning ruins lives

[keen yarrow]

Laughs in Magma 40.2.10 vs 40.2.0

[quiet jewel]

if I check my bug reports on modernfix I highly doubt I will find this to be the case

[vague oar]

Not everyone does, I remember I always used latest.

[boreal blade]

the moment a PR is merged, a -cr release is allocated for it

[sleek tinsel]

Modpacks ABSOLUTELY DO use non recommended versions

[gentle elbow]

yep

[mossy flume]

yeah.

[wooden sage]

Given that I depend on later than recommended builds almost exclusively and don't have people suddenly not use my mods...

[remote apex]

orion, I think you've hit the confirmation bias circle. after an RB, a lot of people use latest

[delicate panther]

ZERO FUCKS ARE GIVEN IF PEOPLE USE CR

[wooden sage]

No my point is which one do you encourage them to use? Which is in the top spot on the website? That matters

[sleek tinsel]

The rb

[wooden sage]

And if the answer isn't "cr" then this scheme is going to have issues

[long ingot]

it always has RB

That has not changed

And we did not make any decision in that direction

[wooden sage]

So the current broken system then

[long ingot]

Any launcher points to RB

Files points to RB

[delicate panther]

it was ALWAYS FUCKING BROKEN

[wooden sage]

Where everyone uses latest but forge keeps trying to push RB... Lovely

[lapis bolt]

Which is bad because mods need non-RB versions extremely often

[boreal blade]

this is what files.minecraftforge.net shows, I assume that most people would read left-to-right and pick latest first

[stoic sedge]

On forge site, it lists RB with Latest next to it but us modders and sane pack makers keep telling people to use latest with all the bug fixes. And I believe most launchers points to latest. Not RB

[vague oar]

That's how most languages work, yes.

[boreal blade]

(rtl languages would like to have a word with you, but still)

[delicate panther]

most people would pick recommended because it's highlighted and shit. also, it swapped recently. it used to be the other way around.

[boreal blade]

interesting

[stoic sedge]

If a new version exists after RB, RB should be hidden

[vague oar]

Up to down languages

[stoic sedge]

Latest should win

[tropic wave]

most people would pick recommended because it's highlighted and shit
in practice this isn't what modpacks use

[remote apex]

last time people were stuck with the RB is 47.1.3 which was caused by forge BREAKING after 47.1.3

[tropic wave]

they use latest

[wooden sage]

And that resulted in us mod devs continuously having to tell them "yes, latest is perfectly stable, use that"

Modpacks tend to use latest. Mods definitely do.

[tropic wave]

because latest is maximum compatibility with mods

[wooden sage]

I'll point out that because neo merged bug fixes latest is generally less buggy than the RB

[tropic wave]

because mods use features that were added between recommended and latest

[sleek tinsel]

So, the proposed change does absolutely nothing other than using the mc version as the base, and appending -cr for non-recommended builds. The stance is still 'use the rb's'. Prs still go to -cr.

[wooden sage]

That's my takeaway, yeah

[quiet jewel]

that is literally how modding works

cpw

[long ingot]

Yes, nothing has changed!

[tropic wave]

the defacto stance has been "use latest" before now

not "use the rbs"

[remote apex]

the stance was never "use the RB", the stance was to use latest after an RB

[tropic wave]

there's no concept of "still use the rbs"

[delicate panther]

no

[wooden sage]

As long as the stance is "use latest" this system sounds fine to me. But the website needs to reflect that and whatnot

Users and modpack makers should use latest. Neo needs to be the first one to tell them that

[delicate panther]

why are we arguing about a system that we've left behind?

[mossy flume]

nothing has changed!

[stoic sedge]

The system to leave behind is recommending RBs always

[mossy flume]

because it wasn't left behind, apparently

[wooden sage]

Because we haven't. You've done nothing but rename "latest" to "cr"

Which... Changes nothing

[delicate panther]

we seem to be unable to change

[vague oar]

The platform is called "Discord", not "benevolent agreement"

[rose halo]

when making modpacks more often than not authors do in fact want recommended builds, but the problem is that you will always have mods in your list requesting latest, and bumping the modpack version to latest is nicer than removing those mods entirely, and everyone snowballs into using latest
so officially, forge recommends RB, but when it comes to actually using forge, users will say "no, use latest"

¯_(ツ)_/¯

[stoic sedge]

It doesn’t matter what Neo “recommends” over latest. If mods keep restricting their versioning to a version after RB, players and pack makers have to move off of RB anyway, defeating its entire point of its name

[mossy flume]

there are certain kinds of change that are objectively bad, and lead to a worse future for everyone involved

[tropic wave]

okay, question: are we going to intentionally merge breaking changes to cr? outside of hypothetical breaking change windows after an mc release

[mossy flume]

Most people seem to be in agreement that this is one of those cases

[wooden sage]

"cr" implies to the end user "use this!" even less than "latest" did

[delicate panther]

so this is one?

numbers?

[mossy flume]

not numbers, the philosophy behind the numbers

[quaint oak]

okay as someone late to this, wth does CR mean

[mossy flume]

the process that dictates how the numbers are to be used

[delicate panther]

what philosophy?

[tropic wave]

continuous release

[quiet jewel]

candidate release

i think

oh

nvm

[quaint oak]

^ problem.

[tropic wave]

this is an important question

[keen yarrow]

what is the difference between 20.1.0 and 20.1.0-cr for you?

[wooden sage]

I would hope not, and everything I've seen from the previous discussion seems to be "no", or at least that was my discussion

[boreal blade]

officially according to maven, candidate release
officially according to neoforge, continuous release

[graceful rover]

Continuous Release, AFAIK

[long ingot]

No, that was decided, just purely discussed as an option, and then discarded

[tropic wave]

okay, I don't have any issues then

[delicate panther]

no plans to.

[quaint oak]

there's an argument about a damn acronym

[quiet jewel]

so then why not just have CR as the thing we all use

and move on

and forget the non-CR variant

[wooden sage]

I think this system is fine as long as CR is promoted as the "end users download this" thing

[tropic wave]

so, modpacks can keep using the latest/cr branch without worrying about mod compat with norge

[quiet jewel]

it's still unclear to me what benefit non-CR has

[stoic sedge]

Basically, we only really need to change “recommended build” to “User Ready” so pack makers and players know from that version on out, no more breaking changes

[long ingot]

Because it turns out, there are people and modpacks which run on RBs - only! We even had a modpack maker in the meeting that asked that question and wanted it!

[stoic sedge]

They just need to know that initial version to know to switch to that Mc version and keep using latest

[mossy flume]

the only change i'd make here to satisfy (i think) everyone, is to ONLY use -cr during the breaking changes period, and every release thereafter is normal non-cr

bam - solved for everyone

[wooden sage]

The latest build, whatever you want to call it, has been and still is what users should be encouraged to use. As long as neo is promoting that, the system in question seems fine to me

[mossy flume]

the solution I suggested months ago

[wooden sage]

Sounds great to me

[keen yarrow]

yes. thank you!

[rapid totem]

in my understanding, the main thing communicated by the Recommended Build was essentially "a mod built and compiled against this version will run on versions after this Recommended Build (up to the next major version)"

that exists such that a modder can feel confident compiling aginst the RB, knowing that their mod will work on later Forge versions (barring things like dependence on bugged behavior)

using the latest builds have always been practice for end users (modpack devs or players), because they contain the latest bug fixes -- fixes which don't exist in the latest RB because of the infrequency of an RB being made (usually, the second RB is made just before switching to a newer MC version)
I note the old Discord rules for Forgecord, where it specifically notes that support is given for

[...] the latest recommended build and very recent beta builds. [...]
(where "beta build" here means the versions marked as Latest on the files site)

[quaint oak]

can we please use -beta or whatever, since all builds are technically CR (automated, right?)

[wooden sage]

Sure, call it whatever. But the general gist of "these are bleeding edge BC window releases" is the core bit

[unborn flint]

this was a "little" kerfuffle

:P

[quaint oak]

I'm 100% on board with an identifier showing we're in breaking phase, also on board with calver because obvious and there's semantic meaning

[wooden sage]

And so stuff merged after that goes straight to the build you're recommending

[boreal blade]

I'd suggest a small tweak where there's a CI build that gets delayed or whatever before being pushed directly as the latest build recommended to users

just in case somebody merges a PR that's so catastrophically breaking that it needs to be pulled

(i don't expect this to happen of course, but it's nice to have a safety net)

[mossy flume]

generally those catastrophic breaks aren't really discovered until someone uses it in production, heh

tends to be a mod interaction - hard to test in forgedev

[boreal blade]

fair

[mossy flume]

and difficult to test in prod testing

[lapis bolt]

See my earlier example

[mossy flume]

because you need to happen to have the mod in your environment

and the situation to replicate it

[wooden sage]

Those sort of breaks will either be discovered before it's merged or when end users start to use it, so yeah, I'd say it's not necessary

[mossy flume]

the ONLY viable solution to that is just to apologise, fix it and move on :P

[tropic wave]

and historically what we've done when that does happen is to just make another bugfix release, yeah

which is fine enough

[quiet jewel]

in my opinion there is no good reason to have more than one branch

[lapis bolt]

Yeah, either fix or revert and be done with it

[boreal blade]

my thought along those lines is that all -cr builds automatically get marked as non-cr builds after like a week or something unless manually halted

[quiet jewel]

I'm still not in favor of this - it delays everything by at minimum a week

[wooden sage]

A week is far too long though. I'd assumed you mean something like a day or so

[graceful rover]

from my understanding, they will have another discussion with the counsel about this, and vote then, or find a better solution.

[boreal blade]

oh definitely

[quiet jewel]

you stop breaking changes with better triage, not with indefinite freezing

and you handle accidents by releasing a hotfix quickly

[wooden sage]

And reverting stuff isn't that big of a deal. Just, like, go on a best effort basis to not need to

[rapid totem]

moar maintainers, moar reviews

[boreal blade]

a week was just the first thing that came to mind for a server like forgecraft (because let's admit, they do a lot of beta testing) to at least have players testing new forge versions before they get pushed and recommended to everyone

[lapis bolt]

Theoretically a day could work but in practice I doubt any freeze time would work because, again, users will not download builds that are marked unstable if they can use a stable one instead, so the number of "testers" goes down significantly

[quaint oak]

meet in the middle and 3 day promotion window?

[lapis bolt]

That doesn't change anything about what I said though

[quaint oak]

more about giving a little bit of time for people to catch stuff before stable

[lapis bolt]

My point is that there will only be very few people to catch stuff if the build is openly marked unstable, so the delay has little to no value

[boreal blade]

I personally think that doing preliminary testing on a server like forgecraft with a small number of people is a good thing, because it keeps the number of people involved small; you don't have to deal with a lot of users reporting the same thing

[quaint oak]

1 day and most will miss it, 1 week and it's taking too long to get into people's hands as "stable"

[wooden sage]

Basically: any small promotion window won't have enough users to actually catch any issues that couldn't be caught before it was merged

[quaint oak]

IMO a lot of the stability issue can also be solved by community/triage feedback on the versions page, too

[wooden sage]

Because you'll be telling people "don't use this" so they... Won't

[quaint oak]

A simple download count can also be an indicator

"oh, version X.1 has 100 downloads, but X.5 has 10 million.. mkay"

[boreal blade]

ultimately, yes, that's the idea

[stoic sedge]

And easier testing in local. Gametests maybe acting like unit tests?

[rapid totem]

i've sampled the oldest page for the Forge downloads page I could see on the Wayback Machine, which is from 2015, and even then the Latest version was on the left, and the Recommended was on the right
sampling a few pages over the years shows the same

[stoic sedge]

Freezes just delay the issue from being found

[quaint oak]

Gametests can't catch client-side (read: rendering) changes

[boreal blade]

what i'm proposing is basically a small safety net for small-scale testing to make sure there are no immediately obvious major issues

[wooden sage]

If it can't be caught pre-merge, you're not going to catch it in a promotion period

[wooden sage]

That's called "build PRs automatically"

[boreal blade]

i disagree

[wooden sage]

Test before you merge

[boreal blade]

not everything can be tested pre-merge

[tropic wave]

train an AI to watch minecraft for you

[boreal blade]

(like rendering changes for example)

[wooden sage]

If you want to shove it on forgecraft - easy enough. Just build the PR and use it there

[rapid totem]

are you advocating for some sort of smoke testing?

[boreal blade]

yes, exactly

[wooden sage]

...wut? If you're building PRs those can totally be tested

Just use the built PR

Have the testers use that

I'm basically saying that your "testing period" should be before the merge, and should be accomplished by building and publishing PRs somewhere

[boreal blade]

i'm proposing a few-day window to do smoke testing with current mods in a user environment before a build gets pushed out to literally everyone as the best build to use since sliced bread

[rapid totem]

(https://en.wikipedia.org/wiki/Smoke_testing_(software) for reference)

[wooden sage]

Yes. Why can't that happen before the merge, by publishing PRs?

[stoic sedge]

? Who’s the tester? Where the mods from?

[boreal blade]

as an example, forgecraft

[stoic sedge]

How’s that different than building the pr and using that?

[wooden sage]

Especially if PRs are built automatically

Which they should be

[stoic sedge]

Like I make the change, build it locally, why can’t I just use that to test a modpack?

[wooden sage]

Heck, if the PR is built and published automatically I can have all my friends test it too

[boreal blade]

one major reason is code integrity signing

[rapid totem]

one could argue that it's more efficient to test a bunch of PRs in a batch rather than each individual PR

[boreal blade]

also that

[tender shoal]

recommended/stable builds are useless when mods tend to overwhelmingly build to latest, imho

[stoic sedge]

And there should be documentation for this too so large pr makers can test large modpacks for breaking changes easier. People should be testing their PRs before asking for merging

[wooden sage]

But yeah, you want to have a period like this? Alright. I get the point. But it shouldn't be longer than, like, a day maximum in my mind

[boreal blade]

in any case, only CI can verify the code used to build a jarfile was legitimate

[wooden sage]

Because any longer and you're just holding up important bug fixes

[stoic sedge]

Who’s reading the signing?

Like what’s the benefit there

[boreal blade]

the mod loader

[stoic sedge]

For like local testing

[quaint oak]

Excuse you, I have a life. I'm not watching the versions screen like a hawk

[boreal blade]

this isn't "local testing", that's the thing

[mossy flume]

peruse the wall of text i sent to cpw.

[quaint oak]

I assume others have stuff to do too; you can be more generous than a day

[boreal blade]

the idea for this x-day window is that the build is available for people who want it RIGHT NOW, and it's also available for people who want to do larger-scale testing

we shouldn't be pushing literally everyone to do our testing for us because we can't be arsed to do proper testing

[wooden sage]

I agree with this 100%. I'm going to try not to say anything more here because at this point I don't think it's really productive, since ultimately this is a maintainer/SC decision and I am neither, but this sums up very well what I think about the whole issue

[boreal blade]

(because no matter how many tests we do before merging, there are things that we will miss)

[quaint oak]

many points agreed, especially that the version could be "pineapple" for all we care. It's the intent.

(can we make unstable builds fruits? that'd be neat actually)

[boreal blade]

unfortunately no because of maven versioning

[quaint oak]

fucking maven. quit ruining the fun!

[mossy flume]

Debian doesn't use maven 😔

[rapid totem]

I think perhaps it's a good time to let the topic of versioning breathe for a day or two; let people digest their thoughts and the views expressed here

[long ingot]

@boreal blade can you post the ordering again? Of the suffixes?

[boreal blade]

    if the prefix is the same, then compare the token:
        Numeric tokens have the natural order.
        Non-numeric tokens ("qualifiers") have the alphabetical order, except for the following tokens which come first in this order:

        "alpha" < "beta" < "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
            the "alpha", "beta" and "milestone" qualifiers can respectively be shortened to "a", "b" and "m" when directly followed by a number.
    else ".qualifier" = "-qualifier" < "-number" < ".number"
    alpha = a <<<beta>> = b <<<milestone>> = m <<<rc>> = cr <<<snapshot>> '<<<>>' = final = ga = release < sp

[stoic sedge]

I think there is the issue of 1.20.2 being so close that there’s a push to get a versioning picked soon

[rapid totem]

you do have a point

[mossy flume]

yeah we're expecting tomorrow i think

[stoic sedge]

Quick, someone crash Mojang computers to delay the update!

[long ingot]

We have a couple more days

There likely won’t be a day one release

But day two or three is the aim for sure

[boreal blade]

For posterity, here's what was proposed in #1129163369874735204:

• mcminor.mcpatch.N-rc is the CI build of the main branch PRs are targeted against
  • e.g. 20.2.12345-rc for CI build 12345 for Minecraft 1.20.2
• mcminor.mcpatch.N is a "stable" build (determined by some process, to my understanding yet to be decided)
• when a -rc build is made "stable", it loses its -rc prefix and is otherwise identical

am I correct with this understanding @long ingot?

[long ingot]

There was actually nothing decided afteralll

[boreal blade]

right

[long ingot]

Cause we in the end did not feel comfortable with any of it

[boreal blade]

i'm only really noting it down since previous suggestions had been pinned for reference

[long ingot]

But yes

That was the whole Idea

To be able to comply with the concept of RBs, Maven, and latest sorting

[boreal blade]

gotcha

[stoic sedge]

I did get confused earlier with the whole delaying of PRs to prod and two branches stuff as that I was against. But what’s described above for just versioning, I’m cool with it. Neo website can then just show lastest and state when it is user ready (not in bc window)

[boreal blade]

Yeah, my suggestion was that the process to determine a "stable" build should be a simple N-day smoke test window, where if no show-stopping issues are reported the build automatically gets marked as stable

[mossy flume]

we have a new proposal incoming.

should address everyone's concerns lol

[boreal blade]

gotcha

glad to hear it, hope everyone's doing better now that we've had a moment to calm down 😅

[long ingot]

I am writing it up

Will take me a minute or twp

[analog badge]

I hope this is mostly sorted out now?

[long ingot]

The following has been decided and will be rolled out: https://gist.github.com/marchermans/8583c6166a771affa025c0f4938747f3

[analog badge]

I left the discussion very frustrated, but from the messages above it seems that the new updated should be ok (haven't read it yet)

[tacit cloak]

👌 not my favorite but functional. works for me

[analog badge]

Not a fan of the unanimous vote, rest is good

[wooden sage]

🎉

I feel like that is warranted

[long ingot]

The unanimous vote is only for shortening

[sleek tinsel]

Only for expediting the windows.

[long ingot]

The idea is that it can not be shortened if one subteam is not ready, regardless of the size of the team

[stoic sedge]

Only took 3750 comments lol

[wooden sage]

Oh lord is that what this channel is at?

[mossy flume]

And a couple hours in voice lol

[sleek tinsel]

Bike shed go burrrrr

[analog badge]

Ok yeah I see - that's good I think

[tacit cloak]

I don't agree with this being bikeshedding but definitely going in circles lol

[long ingot]

With the decision made