Versioning

[wooden sage]

So... I'm really not seeing the argument here

[sleek tinsel]

[1.19.2] works just fine, i use it

[wooden sage]

Huh, maven is funky. Regardless, many (most) people do not use that

[mossy flume]

Huh. Last time I tried that it threw a runtime error because nothing matches an invalid range

[wooden sage]

Especially given that often you need more-than-one-MC-version ranges

In which case you might as well depend only on a forge version range...

[sleek tinsel]

Okay, [1.19.2,1.19.3]

[tropic wave]

that includes both

[wooden sage]

So you're specifying the endpoint anyways

in which case why not just do that with forge versions?

[tropic wave]

if you want just the left one, you need [1.19.2, 1.19.3)

[wooden sage]

ince you have to specify the forge version lower endpoint anyways... why not just specify the upper too, and remove the MC dependency altogether? I mean, you could still use it but on average there's just no need to

Because the forge version fully determines the MC version

I'm just suggesting that that be made explicit

[tropic wave]

that doesn't work if I want to do [1.20.1, 1.21)

because I don't know which forge version will be for 1.21

[wooden sage]

In the modern MC update scheme is that even an issue?

You don't know if it'll be 1.20.4 or 1.21.2 that'll break your stuff

[tropic wave]

🤷‍♀️ I dunno, I still do it though

[mossy flume]

Wasn't the goal here to do 1.x.y+1.20.2 and then bump major with every breaking change, and restart 1.x.y+1.21 when a new version of the game happens

[wooden sage]

And given that forge does breaking changes on major versions - it's smarter to follow forge versioning than MC anyways

[tropic wave]

I leave the possibility open but I only mark my mods as compatible on curseforge if they actually do work

[stoic sedge]

I don’t recall having issues with the current versioning scheme tbh. I’m not sure what actual tangible issue is being solved here

[mossy flume]

In which case you can't merge them into one field anyway

[wooden sage]

I don't think that was ever a goal?

At least not of the "put MC version in build metadata" proposal

Maybe of the "put MC version in artifact name" proposal though

[native flame]

Hence my proposal basically being "keep it but push major a bit less often"

[mossy flume]

Multiple people saying "we should bump major when we breaking change" gave me that impression lol

[wooden sage]

We should do that too but we currently do that

We just need to use -beta so we don't have to do that during the BC window

[tropic wave]

like, what problems would be CAUSED by keeping the current version schemai?

[sleek tinsel]

None

[mossy flume]

There's no clear indication of what anyone actually wants here, all I see is some major arguing over a minor implementation detail of the fmljava language loader's version check

[tropic wave]

if we aren't causing problems then maybe we shouldn't change anything?

[mossy flume]

So I'm just baffled lol

[native flame]

We have some pins of the formal proposals™️

[wooden sage]

Well, assuming you mean just keep the scheme and restart at 1:

• confusion due to center digit 0/1 weirdness
• no easy way to version highly in-dev or snapshot versions if those exist
• duplicate version ranges, encouraging specifying dependencies on forge and minecraft both when that isn't actually what's being depended on
• differing versions at runtime and built time
• version range comparisons in gradle (not in mods.toml) are fucky because the "primary" version is the MC version, not the forge version
  If you mean keeping the current scheme and starting at 48, then add:
• potential confusion because we'll be releasing versions that may overlap with forge versions. If we restart it's easy to tell if someone is using forge when they need neoforge or vice versa when they say "I installed 48.30.2"

Honestly, my biggest gripe is that first point

Even ignoring the MC version stuff, I'd be very happy if we switched to -beta.z for the BC window

[tropic wave]

Well, assuming you mean just keep the scheme and restart at 1:
I was assuming we wouldn't restart at 1 though

[wooden sage]

Then add the last point

[tropic wave]

what if we just skip to like 148

[stoic sedge]

I don’t think there would be much confusion between Neo and forge

[wooden sage]

Cursed, and a bit confusing, but sure?

[stoic sedge]

1.20.2 is a breaking between the two so users can’t interchange them anyway

[wooden sage]

Yes and that'll lead to people using the wrong one

But regardless, not the biggest deal on the list

I tried to list in order of how important I thought they were

My question is basically this: if we are changing versioning at all (and I think we should, to drop the middle digit and use -beta for BC window stuff), then why not make other changes while we're at it, if they are beneficial?

[sleek tinsel]

I don't think there will be any confusion, as we should have our own ModID, it will be blindly obvious to users they are using the wrong mod loader. Probably worth dropping the 'forge' mod id too, unless we are really going to try and keep binary compat.

[mossy flume]

Binary compat is hopeless with mojmap runtime

[wooden sage]

Yeah, the "whether versioning starts at 1 or 48" is, to me, the least important bit

[mossy flume]

So we should IMO drop forge entirely, as a modid in all places

[sleek tinsel]

well, there we go, bincompat go byebye, drop forge modid, magic

[stoic sedge]

Not tags as that should wait for 1.21 with common tag pr stuff

[mossy flume]

Yeah that too

[wooden sage]

Though I would still argue - why 48? It's sorta arbitrary. At that point, why not just calculate a number based on the actual total number of MC releases and use that?

[tropic wave]

don't we already have a 47

or did we already start over at 1

[sleek tinsel]

We have 47

[wooden sage]

Yes but I'm proposing this in the asusmption that we already drop the center digit and start using -beta instead, at which point you can kinda make whatever other changes you'd like I'd say

[tropic wave]

I'd rather just have numbers

[sleek tinsel]

it should either be count(mc_releases) or legacy_offset + count(breaking_changes_windows)

[wooden sage]

For the BC windo? But like, why? What's the advantage?

[sleek tinsel]

the former means we bump it by sorta large increments if we skip major versions

[tropic wave]

I like numbers!

[sleek tinsel]

the latter seems somewhat reasonable, keeps the numbers going up

[wooden sage]

I mean, you need specific knowledge of forge's development process to understand them

-beta is pretty understandable in general

[tropic wave]

yeah but that's worked more or less fine for years

[stoic sedge]

People look at the forge download page instead

[wooden sage]

I mean, you'd want to bump by large amounts with a major version skip, right? In case you ever go back and release for that version later

[rapid totem]

based on a cursory look of past Forge versions, the current major number existed as the 'minor' number of older Forge versions (4 version numbers, major.minor.build.commits), and started at 1 at some point before 1.1 and kept incrementing for each new major Minecraft release

[stoic sedge]

That states recommended and latest and that’s what people used.

It’ll be the same result with Neo. Just with different names I think. Beta label instead of recommended?

[wooden sage]

Anyways, I think whatever decision is made - it needs more reasoning than "this is what has been done". NeoForge is an opportunity to make decisions from the ground up

[rapid totem]

(the last release for 1.1 on the Forge site is marked as 3)

[tropic wave]

whatever decision is made is ultimately going to be made because it's the decision that got the most votes, I think

[wooden sage]

Devs exist... not all devs know about the whole BC process

And most aren't really paying attention to the files page, speaking from experience

[stoic sedge]

Devs start their journey on the forge page where they see recommended/latest. I always went to the forge page anyway to grab the versions for future Mc forges to port too

[wooden sage]

I couldn't have told you what the "0" or "1" meant until I looked into how to PR to forge and figured out how BC windows work

[stoic sedge]

I would be surprised a significant chunk of people get their forge versions elsewhere besides the forge page

[wooden sage]

I never paid attention - I just clicked "download MDK" wherever I landed

Besides all of this - if we can make it less confusing (and -beta is, inherently, more widely understood than 0/1 because it's not some forge-specific thing) - why wouldn't we?

[sleek tinsel]

I think -beta does make sense

<major>.<minor>.<tag_offset>, but when beta/alpha/whatever <major>.<minor>-<beta/alpha>.<tag_offset>. Everything before the tag offset in both cases, just being the git tag, as the current versioning does.

[ashen heart]

we were at that point already but what would major and minor represent?

[rapid totem]

i don't know if it's been mentioned yet, but we do use the "beta" terminology in Forge in at least once place -- the warning displayed when no recommended version is found by the version checker in the promotions file
https://github.com/neoforged/NeoForge/blob/0974ecc143f449087139a6923aa3f0823dce421d/src/main/resources/assets/forge/lang/en_us.json#L144-L145

  "forge.update.beta.1": "%sWARNING: %sForge Beta",
  "forge.update.beta.2": "Major issues may arise, verify before reporting.",

[sleek tinsel]

well, minor is easy, just 'feature groups', or something, whenever there is concencus that sufficient work has been done to warrant a new minor release. (in forge this was always an RB, although, personally, never really stuck to RB's, i dont think anyone else did either)

[native flame]

I also like numbers, and as such am against using letters at all in the version™️

[ashen heart]

which would be in line with the -beta flag as it means the same thing

[delicate panther]

dropping bombs and hottakes: calver

[wooden sage]

If forge had breaking changes on a rolling basis, or if MC itself had a true release schedule, I'd be inclined to agree just based on the scale of stuff

Though honestly the reccommendations I've found about when to use calver line up surprisingly well with what neoforge is like, so I suppose I could be convinced yet

[delicate panther]

I mean, we could do 20230915+123

Because ultimately the version number is pretty arbitrary. We're trying to endow it with meaning but most of the time, it just gets in the way

[wooden sage]

As long as it's based off commit date instead of build time thats not too bad

Though I'd at least separate it a bit for readability - 2023.09.15+123

...but yeah honestly that could work

[delicate panther]

The +<tag> would be the commit tag count

[wooden sage]

Ah, "commits on that day"

[delicate panther]

Or something

Probably something easily related to git

The only thing is how do we associate Mc versions

[wooden sage]

The answer would be "you don't"

[delicate panther]

I HATE thecl current paradigm of a second version indictor

[wooden sage]

Could just prefix the MC version

[delicate panther]

So 20.1-2023.09.15+123

That sucks imo

[wooden sage]

Yeah, that's not terrible

You get the MC version readily available, then a big blob used for ordering and "how old is my shit" and not much else

[delicate panther]

Hmmm

How would depends work

[wooden sage]

You'd just depend on the full version

So, 20.2-2023.09.18+1 or whatever for the first 1.20.2 version

Version ranges would still work on the MC version if you wanted, or you'd be able to specify "after a date" for an open range if you wanted. Hmm. I think you may have sold me on this

[ashen heart]

1. you forgot the 1. in front because that will cause confusion with users
2. using a date as a version number makes it completely impossible to use ranges because you don't know when the next breaking change will happen

[wooden sage]

Yeah you do, they'll happen in the next MC version. Which is part of the version number

[ashen heart]

there have been changes that were considered non breaking that still broke some things

[wooden sage]

Then the version number itself wouldn't help you, would it, in determining if its breaking? You'd have to specify specific versions you know to break things. Which you'd do with the date part of the version

Known, official "breaking changes" - encoded by the MC version
Everything else - it's a commit date. That's it. If you know certain versions don't work you can target ranges based on this date easily

[ashen heart]

the idea was that the major version increments with every breaking change not just once per minecraft version

[wooden sage]

Good news is that we have a BC window system so that we only merge breaking changes between MC versions

Except during the BC windows and we can't reasonably bump that number once per BC then or it would be in the thousands

Basically: if a change is breaking enough to necessitate a major version bump, it shouldn't be being merged anyways outside of s BC window

[delicate panther]

So, 20.2 looms (i refuse to bother acknowledging that 1. exists anymore - it's redundant information)

we need to figure out how neo will version from now on

we seem to have a few proposals here

1. what forge was doing before. so 20.2 will be 48.0.0 with commits bumping the last place until we reach a "recommended build"

2. semver. I'm guessing we start over from 1.0.0? What constitutes a patch, a minor, a major? how will we do those bumps? who will manage that?

3. calver. A joking suggestion from me, but actually, it's not too bad. we do a combo of mc version and the calendar date. so 20.2.2023.09.19+123 would be the 123 build from "tag" and we would bump the date string every build day. 20.2 is obvious and is the minecraft version we're for.

[long ingot]

I would like to point one little piece:

What ever versioning scheme we choose

It has to be compatible with Gradle

[delicate panther]

agree.

obviously.

are any of those three proposals not?

[long ingot]

So something like Calver is not really ideal fo rthat

[delicate panther]

how so?

it uses maven partitioning, so that will sort as expected

[long ingot]

Are you sure

Cause it has more then 4 partitions

[delicate panther]

we can smash some together

so we could do 202.202309.15 or something

[long ingot]

Actually it does not matter

Gradle does not care for the count anymore

So calver could actually work

There is one thing that I miss with Calver Versioning

That is the concept of a stable/recommended build

[delicate panther]

that hasn't been a useful notion in a while tho

the forge stuff seemed basically "arbitrary"

[long ingot]

Yeah

[strong stag]

versions are usually arbitrary in general tbh

[delicate panther]

it seemed as much about when illy had written teh changelog as any actual technical achievement

[long ingot]

Hmm

Okey

So do we allow for breaking changes in the future thgen?

[delicate panther]

what does a breaking change mean?

[long ingot]

Anything that breaks an already existing compiled mod

Basically anything that would trip JCC

[delicate panther]

JCC?

[long ingot]

JarCompatibilityChecker

[delicate panther]

what constitutes breaking vs non-breaking windows?

[long ingot]

Well under MCF we had a breaking change window untill the first RB

Afterwards no breaking changes were allowed which could break already compiled mods

[delicate panther]

i would probably argue that all of 20.2+ will probably be "breaking" in some fashion until we settle on a final 21 build. since we're in the "breaking window for 21" atm

[long ingot]

Forcing us to bend ourselves into 20 angles to get decent PRs merged

[delicate panther]

except that didn't really work out that way. we tried but it was pretty common that we had to break stuff

[long ingot]

Yep

[delicate panther]

or we left important shit out because we'd drawn the arbitrary line in the sand already

[strong stag]

I wonder if it would make sense to hava a "stable" and "unstable/development" branch but that's extra work I don't have time for

[delicate panther]

it's difficult to maintain that illy yeah

[long ingot]

I generally consider a stable build usefull for packs etc

[delicate panther]

yes

[long ingot]

But I don't think having a BC window is a good idea

[delicate panther]

but stable pack builds are usually early in a cycle too

because otherwise the version will have sunset by the time a pack lands

[strong stag]

we could declare a stable and API breakages have to wait till the next window the question is when is the next merge window

[delicate panther]

quite honestly, we can just designate any build as stable

[long ingot]

^

[delicate panther]

and break the next version

[long ingot]

I would simply say

That if we consider a build stable

And well featured

We just mark it as such

And that is it

[delicate panther]

so we can say that 20231004 is the stable build for october

[strong stag]

we could make it time based every other month is a stable

[delicate panther]

ultimately any build can be "stable"

[strong stag]

mhmm

[delicate panther]

as long as it is proven relatively bug free

but that generally requires testing, which means it's not something you can just "say" when you trigger the build. it's a property that comes from having been out and used.

so actually, i think that we should just have calver, and we can post-hoc nominate a well tested build as "stable" for those that care about it

[long ingot]

Seems reasonable

[balmy ore]

it might be worth noting that we have made and discussed the pros/cons of many of these points already in https://discord.com/channels/313125603924639766/1146802696465158174

[delicate panther]

heh. yeah i wondered. we probably should unify these two brainstorms

where can i find a summary @balmy ore ?

on the topic of "breaking" changes.

perhaps we should use something like the guava @Beta marker

for "incoming" stuffs

if a mod doesn't want to rely on stuff that might not exist in a "stable" build

[strong stag]

I would love a @Beta /@Testing/@Unstable

then we could properly incubate APIs

[delicate panther]

@Incubating

along with proper @Deprecation

[strong stag]

but we need to be explicit what it can be ripped away at any time

[delicate panther]

yes

because at this point, the things in flux are: the MC API itself (thanks for not being stable mojang!), incubating features, and stuff that's going to be removed.

[strong stag]

then we need a JEP process no NEP /s

[delicate panther]

nothing else should be in flux in general

yeah, process around new stuff is TBD illy

[strong stag]

Nep Nep

[delicate panther]

but IMO we can easily add an Incubating tag

NAP for NEP discussions

arguably brainstorms are already

[strong stag]

Want me to creating a brainstorm for @Incubating?

[delicate panther]

these topics are all interlinked

[strong stag]

Wish we could merge topics

[delicate panther]

yeah.

it's what it is

there's no ideal platform.

[strong stag]

grabs her spring boot and creates a forum /s

[delicate panther]

/me sobs

forums are the worst

[strong stag]

right mailing lists then :P

we must be like the kernel

[balmy ore]

Some of the major points of the RB thread:

• Some kind of "stable" marker is desirable since not all mod devs are able to update week-to-week, the amount of time one can spend on modding varies greatly
• But it is also bad to wait too long for fixes to be merged
• Ideally aim for runtime compatibility longer term, compile time compatibility less important
  I'm not sure we actually reached many solid conclusions on reading back through that thread, tbh

[delicate panther]

where should the stable marker be? does it have to be in the build artifact itself or can it just be metadata elsewhere?

otherwise i would tend to agree with those points

[strong stag]

would a diffrent channel be good for stable?

[delicate panther]

what's a channel?

[strong stag]

maven.nf.net/stable/

[delicate panther]

that's a repository

[strong stag]

at work we call them release channels (i've been poisoned)

[delicate panther]

we could do a promotion thing- promote known good builds to a stable repo

[balmy ore]

it seems people like the idea of promoting a build to stable after being tested, so I think that implies doing it in metadata is a-ok

[delicate panther]

yeah i like it too

the question then is, where does this metadata live? do we leverage maven somehow?

or DIY it, as we have done previously

[strong stag]

we could do calver + build number and when build number is 0 it's stable? or something like that

[delicate panther]

rename the artifact illy?

[strong stag]

that works to

[delicate panther]

because rebuild doesn't seem particularly efficient

BUT

that means the artifact can't know what status it is. Hmmm

[strong stag]

does the artifact have to know?

[delicate panther]

does that matter? does neo need to know it's a stable release?

[strong stag]

i'd argue it doesn't

[delicate panther]

i would agree

[strong stag]

honestly stable would ideally be declared with a tag pushed to the repo

and CI does the rest

[delicate panther]

hmmm

if we're retroactively pushing the tag once we're confident of stability

then the + number isn't really meaningful, since it could change

[rapid totem]

i'd like to note that Forge does have a beta warning indicator, but it only appears if there is no recommended version found in the promotions.json for Forge (and so only appears when the update checker for Forge is enabled)

[delicate panther]

yeah i know about that. that's not been very useful for a while

[strong stag]

we could add unstable/bleeding and logs to the branding

[rapid totem]

firefox developer edition style, where we change out the colors

[delicate panther]

different animals 😄

[rapid totem]

[delicate panther]

rabbits for unstable builds.

[strong stag]

imma get some food and let it stew some more

[silent ginkgo]

I love soulfirefox

[strong stag]

Oh do we we want an ap for @Incubating

[tropic wave]

I'd rather have one breaking change window per mc version like we currently have

[delicate panther]

@tropic wave what does a breaking change mean?

[silent ginkgo]

Basically the only reason I use nightly

[strong stag]

I define it as breaking our APIs

[delicate panther]

which ones tho?

[tropic wave]

breaking binary compat with existing mods built for a stable build of norge

[strong stag]

^

[delicate panther]

which ones tho

[tropic wave]

oh hmm

[delicate panther]

is it "breaking" if we're adding new stuff and deprecating shit

see the Incubating discussion above

[tropic wave]

no, I don't think anyone would consider that breaking

[strong stag]

depricating isn't breaking

[delicate panther]

nor is incubating IMO

[tropic wave]

changing or removing stuff, yes

[strong stag]

I agree

[delicate panther]

we already don't do that

[silent ginkgo]

breaking -> stuff breaks (e.g. crashes)

[strong stag]

breaking is making them not being able to compile on an updoot or crashing

[delicate panther]

our API is stupidly stable, given teh environment it lives in

generally, breaking changes are only done to adapt to incoming MC changes

[rapid totem]

this reminds me that #1146802696465158174 exists/existed

[delicate panther]

indeed and @balmy ore pointed it out. there's not a lot there that we're not covering here too now 😂

[long ingot]

that is terrible for development IMHO

[delicate panther]

orion: my point is that most breaking change isn't really breaking. it's incoming stuff in flux (incubating) or stuff being marked for removal (deprecation)

[remote apex]

if we break at any time we're going to create a 1.19.3 vs 1.19.2 problem

[delicate panther]

apart from the "oh shit MC blew our shit up again"

[long ingot]

I am not saying we should break at all cost

[delicate panther]

_what does breaking mean @remote apex _

[long ingot]

I am saying that we should have the ability to do it

[delicate panther]

we should continue to strive for compatibility

[tropic wave]

the alternative (more than one breaking change window per mc version) means that you get in situations where half the mods made for e.g. 1.21 only work on norge 50.1.0 and the other half only work on 50.2.0

[long ingot]

If a much better API or system comes around

[strong stag]

isn't that what @Incubating is for though in theory

[long ingot]

We had so many chances under MCF to improve the API / Systems

[delicate panther]

yes it is illy

[long ingot]

But they died, because we had to "wait" for the next BC

[remote apex]

binary breaks, no one is arguing adding a new feature is breaking...

[delicate panther]

and i think that new shit should use incubating.

no maty. incubating can change in a breaking way

add it as incubating, change it as incubating. that can break shit

[long ingot]

I just checked some of the larger PRs of the last year, a good portion were......

Simply because it is nearly impossible to properly maintain compatibility in most cases

[remote apex]

adding a new method is not breaking, adding a new method and removing the old one is

[long ingot]

For larger stuff that is

[rapid totem]

i'd like to note the various annotations under JetBrain's @ApiStatus, including @ApiStatus.Experimental, @ApiStatus.Obsolete, @ApiStatus.ScheduledForRemoval, and such

[delicate panther]

most of the brainstorms are breaking too

[long ingot]

Which sometimes is necessary

[remote apex]

adding a new method and deprecating an old one is not

[strong stag]

it would be nice if we could make Incubating changes like the jdk does and hide it behind a module

[delicate panther]

sometimes you can't add the new one without removing teh old one, because you changed the underlying

it would be nice yes illy. a lot of work too

[strong stag]

I'm not arguing the amount work

[rapid totem]

long-term goal, perhaps?

very-long-term goal

[delicate panther]

yeah

but IMO we shouldn't be hidebound to "only breaking for 1,2,3,4,5,6,7,or 8 weeks after and mc release"

[remote apex]

if you remove an old method it is a binary break, if you don't like it take it to oracle 😛

[strong stag]

once things stabilizes for me(a week or two) I might seriously look into something like

[delicate panther]

k

biab. work calls

one thing to think about. if we only breaking change for the next 2 weeks. how much of brainstorms work is going to make that cut off?

[remote apex]

the problem is that we're working with minecraft, an unstable environment. we want to be stable else we're going to create an arguably worse environment

[long ingot]

None

[remote apex]

people do not have time to update a mod that worked after 2 months for the same mc version just because we decided to break something

we should try to break at the start and then let the version stabilize

honestly if I need to update my mod 10 times in 3-4 months I'd rather not

[long ingot]

We would still have the concept of a stable/recommended build

The question just is, do we want to prevent breaking changes after the rb

[rapid totem]

IMO, we shouldn't allow breaking changes after a marked-stable build unless and until the version is sufficiently changed to mark it distinctly

[balmy ore]

I'm sorry if I'm being a bit thick, but what exactly is a RB if we don't prevent breaking changes?

[rapid totem]

for example, if we're on e.g. 1.0.7 and we think about making a breaking change, we must bump the version first to 2.0.0-alpha.1 (or similarly) before we consider pulling any kind of breaking change

[wooden sage]

I think having a BC window, as a rule of thumb, is a good idea. Mid MC version breaks are just plain bad. That said, I think any versioning scheme we use should either encode that information explicitly (by use of something semver like and a beta prerelease stuff) or not at all (calver).

But yeah, I don't see any reason to throw out the idea of stable builds guaranteeing "no breaking changes till MC does them"

That's a useful thing to have

And otherwise nobody wants to write mods because "it's not stable enough yet"

It also means that people like me with no spare time can update all our mods at the first "stable" build, then sit around and do nothing till vanilla updates

[strong stag]

If we had a stable mc version we could do breaks after we declared a stable but we live on a moving Target so our goal is to make life least painful as possible for our end users

[wooden sage]

What do you mean by a "stable MC version"?

Oh, wait, I just finished parsing that right

And yeah, I agree with you. MC is constantly changing, so we should time neoforge breaking changes alongside vanilla changes for a lack of pain

[remote apex]

yea, we need to be the one to try to stabilize it

else people will just use say 47.1.3 for the entirety of 1.20.* and be done with it

[wooden sage]

I'd say having a dedicated "breaking changes window" of a fixed length isn't necessarily great. But at some point a designated stable build needs to be made, and neoforge needs to not make breaking changes till the next MC version. I emphasized "needs" there because frankly, without this you're going to lose a ton of modders

[strong stag]

I don't mind an incubator tag for things that we explicitly Declared unstable then we can break as much as we wish

[wooden sage]

I do think that if you could build PRs and put artifacts somewhere easily accessible that would simplify it a bit as it would allow easier testing of PRs by modders before they're actually part of forge

Which means there's less of a rush to get everything in pre-first-stable-build

But yeah, all of that said, my personal preferences for versioning is either "use -beta for BC window", or "calver with MC version, and just list how stable it is on the website". I'll note that if calver is used, you'd assume that for any version after the first stable one, there'd be no breaking changes till the next MC version, so the version range stuff isn't really an issue

Basically, I'm advocating for either "explicitly all the meaning", or "bare minimum meaning needed to write sensible version ranges", in terms of versioning

[tacit cloak]

so uh.... what's the currently "winning" standard?

[woeful sphinx]

cpw.

[Reference ➤ ](#1137179119713529876 message)So, 20.2 looms (i refuse to bother acknowledging that 1. exists anymore - it's redundant information)

lukebemish referenced · Sep 19, 2023, 6:07 PM

[tacit cloak]

so still multiple choices?

[wooden sage]

In terms of "semver like" it's some combination of 2-3 digits, possibly with a -beta.z for BC window, and maybe with a +MC version or maybe not. Lots of proposals there

[tacit cloak]

yeah

[wooden sage]

You guys will probably have to actually vote on it somehow but I'll leave the Herculean task of organizing that up to you

Note that there's also been discussion of removing the "no BCs except in a window near MC version changes" policy, which... Is in my opinion a very bad idea for, like, actually convincing people to adopt neoforge

[rapid totem]

in reference to cpw's suggestion of "who will manage [bumping versions]" in #2, I would suggest (as I've suggested in the past, iirc) having a sort of release manager role (appointments to be determined), where that person is responsible for pushing a button for making a release and determining which versions to be pushed, and determining when a release should be done

[wooden sage]

Another option would be to dump the third digit and stick with automatic bumps

[rapid totem]

having someone in such a defined role would also solve situations of people thining someone else will be doing the release

[supple panther]

I do think some people appreciate having recommended builds

As long as the recommended build does not get frozen for months it can be useful for people who don't want to worry about using an untested release

And baking recommended into the version number is useful IMO

[delicate panther]

this will happen anyway. it already has. the fact that all future 20.x versions will be breaking guarantees it

[rapid totem]

"frozen for months"? could you clarify?

[supple panther]

In my exerience, Forge recommended builds did not often increment with the exception of the breaking changes window. Was notably a problem on 1.18

[delicate panther]

but what does it mean to "release"?

BC windows IMPLY frozen for months.

that's simply facts

the only reason 19 didn't is because .2 to .3 blew everything up

[wooden sage]

See, that's why my thought was to just have a "stability marker" of the build - so, once the first stable build is out, everything after that is too until the next MC version and it doesn't get frozen

[delicate panther]

because that effectively means, we have the next 2-8 weeks to implement all changes.

then we're frozen until after 21 lands

[supple panther]

I am not talking about frozen in the sense of breaking changes

[delicate panther]

rinse and repeat

[supple panther]

I am just talking about the version forge tells people they should use being a months old release

[delicate panther]

bc windows => frozen state

[wooden sage]

We need BC windows though

[delicate panther]

what KIND of BC windows

i see you haven't read any of the "incubating" discussion

[wooden sage]

Some time after any given MC release, neoforge should release a version with a guarantee of "we won't break shit till the next MC version"

However you name it, that's sorta what has to happen

[rapid totem]

IMO, that would mean "causes versioned artifacts to the pushed to the public Maven repository"
in the current system, that would be done automonously by the CI for each push to the master branch
in my suggestion...?, it would be done by the CI only upon the command of a person -- the release manager
the release manager would handle checking there's nothing pending that needs to get in egregiously (like a major fix PR or such), tags the version for the release, and pokes the CI to make the release

[delicate panther]

what does "we wont break shit until the next MC version mean" what's "next" MC version? next snapshot? next unstable? next stable?

[wooden sage]

Because you're working on MCs schedule here

[wooden sage]

Next MC release

Especially with the new release schedule, that's not a long time

[delicate panther]

so your suggestion sciwiz is that we don't get automatic builds at all?

what's "Next MC release"? unstable? snapshot? stable? other?

[wooden sage]

Do you have a link or can you summarize?

[delicate panther]

you haven't specified. and most choices result in deep ossification

[wooden sage]

It's exactly what it sounds like. The next full MC release, of the sort people actually write mods for

[delicate panther]

people write mods for snapshots, unstable releases and stable releases 😛

[wooden sage]

So, if 1.20.2 is out it's either 1.20.3 or 1.21 depending on what gets released

[delicate panther]

you really are not being specific here

[wooden sage]

Pick the obvious one cpw...

[delicate panther]

obvious to you is NOT obvious to me

[wooden sage]

Obvious to the average coming-from-forge modder

[tacit cloak]

Okay then... Have I forgotten anything?

With regard to version format:

1. 🟧 - 1.0.0 = breaking changes, 1.1.0 = stable
2. 🟣 - 1.0.0-alpha.1 = breaking changes, 1.0.0 = stable (keep in mind this makes versionRange in the toml require special treatment if you want to use an alpha, eg versionRange="[47,48-alpha)")

With regard to restarting:

1. 0️⃣ - restart
2. 1️⃣ - keep, with major bump every breaking changes window (whenever that may be justified)
3. 2️⃣ - keep, forge-style bumps every time there's a new mc version (minor or otherwise)

With regard to mc version in maven artifacts:

1. ⬅️ - neo:1.20.3-1.2.3
2. ➡️ - neo:1.2.3+mc1.20.3

With regard to version in the mod metadata (mods.toml dependencies)

1. ❌ - mods.toml excludes mc version, eg. version="1.2.3" (same as forge)
2. ✅ - mods.toml includes mc version, eg. version="1.2.3+mc1.20.3"

Or...

Alternative: 📆 CalVer based: mcver-date+buildcount 20.2-20230921+12

[delicate panther]

yes. calver 😛

[tacit cloak]

what's that?

[delicate panther]

2023.09.18

[wooden sage]

20.2-2023.09.19+123

[tacit cloak]

oh I hate that

[delicate panther]

it grows on you 😛

[tacit cloak]

that's the least informative for anything other than knowing the date

[wooden sage]

It grew on me and I hated it at first

[tacit cloak]

which like, I have absolutely 0 interest in knowing when I'm modding

[supple panther]

I feel like being specific is not needed when they are just trying to describe what forge has done in the past, nothing new here

[delicate panther]

yes. because quite honestly, the others are just as meaningless and require much more mental processing 😛

[wooden sage]

That's the point. If all versioning is arbitrary and unintuitive to understand... Might as well make it truly arbitrary and not play pretend

[tacit cloak]

but it's not arbitrary?

[rapid totem]

in my view, a release should be published deliberately by a person
we could have commits be built and published to a Maven repository, but only as snapshots

[delicate panther]

it is.

[tacit cloak]

the point is to have the MOST information in the version

[delicate panther]

1.0.1 is just as meaningless as 2023.09.19

[tacit cloak]

with the least numbers/letters

no it isn't

[delicate panther]

in fact MORE so

[tacit cloak]

1.0.1 tells me it is one build after 1.0.0

[delicate panther]

how recent was 1.0.1

[wooden sage]

Eh, is that the point?

[tacit cloak]

and 2.0.0 tells me it's one breaking changes window after 1.x.x

it is for me!

[delicate panther]

but what's a breaking changes window?

[supple panther]

one major advantage to date formats as a mod dev is when a user tells me they have 2023.05.12 installed, I immeditely know they are on a 4 month old release

[tacit cloak]

all the time I have spent here trying to come to an agreement

has been for the purpose to find the most useful versioning scheme

[rapid totem]

continuous integration yes, continuous deployment no (since we're publishing an API used by consumers, who have need to depend on things like API stability and the version communicating that, etc.)

[tacit cloak]

a point after which mods are probably not compatible.

[delicate panther]

who decides that?

[tacit cloak]

we do, when mojang doesn't decide for us

[delicate panther]

and what is more meaningful? if we tie breaking changes to minecraft, is 20.2-2023.09.18 vs 20.3-2023.09.19 ?

[tacit cloak]

if mc has breaking changes, we bump

if we start merging breaking changes PRs, we bump

[delicate panther]

we never haver in the past. why start now? we're already making the point that we're never going to BC outside an MC bump. read up

[supple panther]

I think the question you have to answer: will forge ever do a breaking changes release that is not caused by a minecraft version bump?

[delicate panther]

we have a LOT of different camps arguing here

that BC windows are necessary

[supple panther]

Thus far forge has done so but only within a couple weeks of a new release

[delicate panther]

because otherwise we split the community somehow

[supple panther]

that could be accomplished with an unstable marker in the version intheory, not a whole extra number

[delicate panther]

why does the build or the mod need to give two shits about its status? isn't the best measure of stability, well, testing?

[tacit cloak]

no I'm busy I want to knowwhen shit is probably broken so that I can reserve time for it

[delicate panther]

?

[mossy flume]

the proof is in the pudding, as they say. so we best get to making a damn good pudding.

[wooden sage]

If we only BC at or right after a MC bump, then the only part of the version needed to know about BCs is the MC version, and the stability of the version. The second part isn't even necessarily that relevant, because if you're using a non-latest version intentionally you'll know and if you're using an old version calver tells you

[delicate panther]

my point is, generally, the best marker of stability is the marker given because it's been widely tested and hasn't found any significant faults

[supple panther]

because then a mod dev can tell at once glance "you are on an unstable forge build, you should upgrade past that to the actually stable forge release past breaking changes"

[wooden sage]

That's the main benefit of calver, and what convinced me when I'd hated it originally - it tells you exactly how out of date your forge version is

[delicate panther]

exactly

[tacit cloak]

but the chronological time doesn't really matter

[delicate panther]

the most relevant thing is "you're running a 4 month old neo"

[supple panther]

I am assuming forge will continueto do a breaking changes window and a no breaking changes past X point. I want to know if people are on a version before X with minimal effort

[wooden sage]

Which is huge when trying to figure out issues! Oh, it's a 6 month old version? Probably should try with a new one!

[delicate panther]

why knight?

[tacit cloak]

I find "you are running 50 builds behind" a lot more informative than time

cos changes are proportional to builds, more than time

[supple panther]

Because people use stuplidly old versions and post issues with them on my server

[wooden sage]

Right, but how do I know what "latest" is?

[delicate panther]

exactly

[tacit cloak]

the same way ytou know latest with calver

you go to the website

[wooden sage]

It's as easy to look up "what date was stable released on" as it is to know "what was latest"

[delicate panther]

err. i know the date already without visiting a website 😛

[tacit cloak]

unless you all want neo to have daily builds even if there are no changes

then it's possible for the latest build to be == the build you have

[wooden sage]

With calver you can easily tell that something is likely not latest

[tacit cloak]

it just happens that no one has merged a PR in the past 20 days

[supple panther]

well, assuming there was a release today

[wooden sage]

If it's 2 months old, it's probably not latest

[supple panther]

take 1.18.2, its done getting releases. What is the date of the latest release?

[delicate panther]

exactly luke

[remote apex]

note that I've specified a specific forge version, not only a mc version

[delicate panther]

so, my question then.

[tacit cloak]

if it's 2 months old you probably forgot when was the last time you checked for updates, so you probably should go to the website regardless :P

[delicate panther]

what are we overloading the version number to be a proxy for?

how fresh is the build.

is it stable or unstable.

is it breaking or not breaking.

any more?

[supple panther]

major MC version

either a flat number (e.g. 48) or the actual version (e.g. 1.20.2)

[wooden sage]

I'd just like to say that I think thinking in terms of a BC window is kinda backwards. If the goal is stability, we should think in terms of a "stable window" instead - going from the first stable release till the next MC version

[tacit cloak]

yeah the specific mc version should appear on the filename somewhere

for the benefit of users

[supple panther]

well yes, but I am talking the version you match against in mods.toml

[delicate panther]

should all this information be encoded in the version number?

[balmy ore]

that seems mostly a semantic difference?

[delicate panther]

remember the version number is a technical artifact with specific meaning to our build tools

[supple panther]

being able to match against [48,49) to mean "until forge next deems a minecraft version breaks everything" is nice to have

[tacit cloak]

similar reasoning: a user sees "you need forge 48.0.1 or newer to use this mod", it doesn't tell them "this mod is for 1.20.2 and you are running 1.20.1"
if the mod metadata said "1.20.2-48.0.1" then it's immediately visible

[delicate panther]

ok. biab again.

[supple panther]

if forge can match against weird versions like that, then sure

though there is always the possibility of 1.20.3 working with 1.20.2 mods, nice to not need to update version ranges

[wooden sage]

It's a difference in how stuff is being thought about. There's been a big focus here on "when can we merge breaking PRs", which makes sense given the channel we're in, but the way we should be thinking about it from figuring out a versioning scheme is "when can I (a modder) safely know stuff won't break"

[tacit cloak]

that's why my mods never specify an upper bound for forge version

[supple panther]

if forge is 48 for 1.20.2 and 1.20.3, its an indicator they both work

[tacit cloak]

    modId="forge"
    versionRange="[46.0.12,)"

    modId="minecraft"
    versionRange="[1.20,1.21)"

[wooden sage]

That would imply no time to merge BCs between the two though. At all

[supple panther]

I doubt version matching will let you match 1.20.[2|3].48.+

[supple panther]

well yes, that has happened in the past

its hard to say if it will happen again with mojangs current release model though

[balmy ore]

if the number didn't bump, that means we chose not to break though

[tacit cloak]

it doesn't, that's why picking a version is not straightforward and we need to make compromises

[balmy ore]

if Neo does break the version would bump despite MC being completely compatible

[tacit cloak]

that's why would prefer to keep a forge-style versioning number, but with the major part indicating breaking changes

[wooden sage]

I'd say it's easiest just to start the forge version with, like, 20.2. So you'd have 20.2.0-beta.0 as the first 1.20.2 release

[tacit cloak]

because I'm a modder more than a player and that's a million times more convenient for me

[supple panther]

the way I see it, in mods.toml you can already ask Minecraft for the Minecraft version if you want to condition on that

If I wish to condition on the forge version, I should not be specifying MC version again, its at best redundant and at worst conflicting

[balmy ore]

I don't see what we gain from moving to calver, I do see what we lose

[wooden sage]

Has forge ever not bumped the major version with an MC version bump?

[tacit cloak]

no

forge's policy is to always bump

or was, at least

all minors, bump

[wooden sage]

In that case, it's really just "MC version but expressed another way"

[tacit cloak]

even for tiny bugfixes

[wooden sage]

And is just as redundant as the MC version used explicitly would be

[tacit cloak]

that's the part of the forge versioning I don't like

[balmy ore]

we don't need that specific policy though, I agree that's unnecessary

[wooden sage]

At that point I'd use 20.2 instead of 48 and go from there

[supple panther]

I thought I remembered forge not bumping major at some point, 1.10ish

and again near the rapid 1.16ish releases

but I could be misremembering

[wooden sage]

Is it likely that neoforge will do such a thing in the future, with Mojang's current release schedule?

[balmy ore]

but what if 20.3 is a bug fix and Neo is still compatible

[supple panther]

minecraft 2.0 drops then

[balmy ore]

in 19.x they did have minor version bug fix updates

[wooden sage]

Then people will need to update their MC version ranges in their mods.toml anyways, no?

So no big deal

[tacit cloak]

here's my ideal versioning if maven ranges weren't annoying:

• 1.22 -> 50.0-alpha.1 during breaking changes, 50.0.1 after breaking changes
• 1.22.1 (minor bugfix) -> 50.1-alpha.1 during breaking changes, 50.1.1 after
• 1.22.2 (break) -> 51.0-alpha.1 during BC, 51.0.1 after

[balmy ore]

if we're relying on the MC version range in the mods.toml, we're back to not needing the mc version in the neo version at all though?

[tacit cloak]

no you still want it for the filenames, which means you have it in the maven artifact version

like forge now

[balmy ore]

yeah. I meant as opposed to luke's proposed versioning

[supple panther]

Doesn't maven ignore stuff after +?

so in theory, 50.0.1+alpha could be the format during breaking changes, then 50.1.1 after

also puts alpha last so it stands out to users

[tacit cloak]

+x sorts after, afaik

[woeful sphinx]

Maven versioning: 50.0.1 < 50.0.1+alpha

[tacit cloak]

has to be -alpha if you want it to sort before

[supple panther]

there would be no 50.0.1 though, only 50.0.1+alpha

[balmy ore]

alpha and beta are special cases aren't they? (I think I recall maty having "fun" with this stuff )

[supple panther]

or - if you wish, sure

[tacit cloak]

- has issues with maven ranges

[supple panther]

its just a tag tossed in the version number to stand out

[tacit cloak]

although if you hardcode the .1 it doesn't matter

but I really find that ugly

unless wait

I see now

your suggestion is to do the counter as usual

[strong stag]

What's the list of the current proposals

[tacit cloak]

so like, you'd have 50.0.456-alpha

[tacit cloak]

(removed the bot embed, see pins for the original message)

[supple panther]

yeah, its basically just like what forge does, but if the middle number is 0, you toss alpha at the end

[whole dagger]

Personally: 🟣0️⃣➡️

[visual locust]

question: is the mod version still gonna be in the mods.toml and the gradle.properties or just one of those now?

[strong stag]

I think we're at the point of going in circles with the new release around the corner I think it's time to put it up for a vote by the end of the week

[tacit cloak]

that's just replacement strings. the version always ends up in the mod metadata either way

you can hardcode into the mods.toml, you can use file.jarVersion + manifest

or you can use gradle.properties strings + processResources

so none of that matters here for this discussion

whatever version scheme is chosen, the mods.toml syntax doesn't change

[ashen heart]

I'm for 🟣0️⃣➡️❌

[mossy flume]

purple dot zero to red x?

[ashen heart]

the options in gigas post

[mossy flume]

oh i didn't even see that lol

[analog badge]

Please someone just make a good decision and stick with it

This discussion has lasted for too long IMO

[supple panther]

but bikeshedding is the one thing that modders are good at

[tacit cloak]

oh I should note, I edited the original to add the CalVer option cpw suggested, but that doesn't reflect on the bot's quote

so use the pinned message instead

does discord have a way to react with a given emote?

[mossy flume]

yeah

[tacit cloak]

they should make it so "add reaction" on top of an emote suggests that emote

note by given I mean, one from a message

[delicate panther]

A question that has occurred to me. Is this bike shedding?

[quiet jewel]

considering how long this has been open for I'd say yes

[delicate panther]

If so, then surely the status quo wins by default?

Because we'll just end up going round in circles

[quiet jewel]

The status quo is not ideal because it means our versions overlap with Forge

[delicate panther]

I mean, we can do a number reset.

[quiet jewel]

that being said it might be better to solve that specific problem than redo the whole versioning system entirely

yeah

[delicate panther]

So we start at 20.2 and go from there

Syncing our first two digits with Mc version 😀

[quiet jewel]

umm

[delicate panther]

Or 202.0.0 if we want two digits of freedum

[quiet jewel]

how does that work for recommended builds then

[delicate panther]

This is the essence of the problem I suspect

[quiet jewel]

what if we just go back to four digits

20.2.0.0

RB is 20.2.1.0

[delicate panther]

We have some sort of need to overload our version number with non technical data

I'm going to admit I'm not sure why

The longer things go on, the more evident it is to me that the whole scheme is arbitrary and meaningless

But it seems that others believe differently

Anyway

In my opinion, we should be putting the meaning elsewhere

Not in some sort of heavily overloaded number scheme that you require documentation to comprehend

[quiet jewel]

the version scheme shouldn't be overloaded, but by the same token its nice to know at a glance if a build is stable or not

[delicate panther]

But what makes a build stable?

The number of times x.1.0 has been fucked is more than not

So it's rarely stable

It is usually.1.2 or .1.3 before we hit "stable"

And yes there have been retroactive renumberings to hide this shit

It's stupidly gross

Anyway. I guess someone wants to keep doing that

Quite a lot of you in fact

[delicate panther]

This is the literal definition of overloading the semantic meaning btw

[quiet jewel]

...what

[delicate panther]

There's been a few occasions where we've renumbered to make .2 a .0 so it's a recommended build because we missed something or other

It's one of the main reasons we couldn't enable caching for along time, because the file changed 🤣

[quiet jewel]

that's like force pushing at that point though

[delicate panther]

Heh

[stoic sedge]

in that case, yeet the middle number meaning recommended" as there should not be a need to go back like that

also lets us be able to keep incrementing the version if we do release a recommended build and realize later that it is really still in flux

[quiet jewel]

So then the recommended build is just documented somewhere else, and can be any version number?

[quaint oak]

I argue one of the points made (but the filename should have MC version!!!1) is easily avoided by not having maven be your player-facing downloads.. once a build is made it can be hosted in a download center with whatever filename you want

versions are important for code and scripts, not so much humans

players could see "Oh I'm running Forge Apple instead of Grape" and those are just as meaningful if you assign the scheme (see: Ubuntu)

..TL;DR if your two systems don't agree on how to version, tweak the public-facing version differently to make THAT easy

[analog badge]

It doesn't mean that it doesn't have bugs, but it means that modders shouldn't have to change their code anymore once the build is stable

[native flame]

(that was why recommended was such a terrible moniker)

[tacit cloak]

hmmmmmm 20.2.(build) I don't hate, but it doesn't represent the idea of major = break which I personally like
the unstable/stable can be tagged after, like 20.2.25-alpha

I still prefer to keep the existing version system, myself, but I wouldn't hate that one

[native flame]

I still defer to #1137179119713529876 message
which is mostly status quo :p

[ashen heart]

squashing can lead to overlaps and f'ed up ordering

[analog badge]

We should use 0 for snapshots, 1 for BC window, 2 for stable, IMO

(for minor)

[long ingot]

So we agreed that we still only have 1 BC?

[ashen heart]

I am completely against encoding such information into a number because it requires prior knowledge of it and isn't as easy to understand as beta = unstable and alpha = very unstable (in this case snapshot)
I'm also against having the mc version in the artifact name

[tacit cloak]

IMO snapshots should get their own release channel, and yes that means the mods.toml becomes more awkward

[quaint oak]

Can we PLEASE not put that in the mods toml, and have it in gradle instead

[analog badge]

IMO we don't have the choice there

[long ingot]

Okey

[analog badge]

More BCs would fracture the ecosystem

[long ingot]

Not the hill I want to die on

Because IMHO we will likely never get to stable at all anyway

[analog badge]

Yeah but we try our best not to break stuff

[long ingot]

With the current release cadance

[long ingot]

That is not really an optoin

Either you are stable and indicated as suchj

Or you are not

"Trying too" holds 0 water

[analog badge]

I mean that when we are stable

[long ingot]

It is just an indication

[analog badge]

We don't break stuff

[long ingot]

What I mean is

That the BC won't be two weeks

But more like 1 to 2 months

And then another week or two to pick a stable version from there

So all in all we are 2,5 months from first release were I would personally consider a release to be properly stable

[analog badge]

Do we need that much? Except for 1.20.2 we shouldn't have too many changes in store for a version

[long ingot]

The last forge versions all had BCs of about 4 to 6 weeks

And lex picked the rec. version at random when he felt like it, at least that is what it felt like to me

And that is something we should avoid

We should figure out; what is coming down the pipeline

And make a decision from there

[analog badge]

I completely agree

[long ingot]

Which IMHO means, more likely then not

We will match that 4 to 6 weeks

If not exceed it

Depending on the Mojang changes

And the ones we want to introduce in that version

So 1 to 2 months is not unrealistic

[analog badge]

Yeah true

[long ingot]

So

I am not sure what the time frame was between .1 and .2

But my stomach says, roughly 4 months

From a useability standpoint that would mean that we would have a stable version roughly half of the time

But from an engineering standpoint that means that we are only able to do hamstringed improvements half of the time

[analog badge]

That's fine - we can already design things the other half of the time (as we've been doing for 2 months)

[long ingot]

Is it?

I know more then one PR, pretty sure that includes some of yours, which died because they had to wait for the next BC and that caused people to loose interest / time

The concept of a BC is fine

[analog badge]

We don't have the choice for modpack stability

[long ingot]

But I don't know of a single product that literally freezes the main working version for changes, for half of its production time

What do you mean "for modpack stability"?

[analog badge]

Features can still be added in a stable phase, it's just BCs that should be avoided

[long ingot]

The declaration of a stable version, is arbitrarily defined, based on our gut feeling of the state of the version, yes?

What prevents us from releasing two stable versions for each MC release?

There is nothing defined anywhere that those two stable releases need to be compatible with each other

Escpecially when it comes to new features that were just added, and need fixing

Or features that mojang added

[analog badge]

We can't ask ALL mods to update to a new major Forge version just because we couldn't wait a bit

[long ingot]

Which need modification to work nicely with modded environments

[analog badge]

In those cases we try our best not to break existing mods, but may have to if there's REALLY no other choice :/

But it should not be something that happens often

[tacit cloak]

IMO neo shouldn't become stable if there's vanilla breaks left to resolve, but neo api breaks can be pushed forward, so no point adding more breaks per mc release

[long ingot]

Really, I would propose that any system which we add, should be annotated with @Beta or @Incubating

[analog badge]

Let's not do that

[long ingot]

For at least one full MC Cycle

[analog badge]

Fabric does it for some things and it's a disaster

So the capability rework would be incubating? What if my mod uses caps then? Do I just not use them?

[long ingot]

That is up to you as the modder

[analog badge]

No, it's a terrible choice

[long ingot]

We indicate to you that we are not 100% sure of the stability of this API Surface and that we might need to make changes to it to fix bugs etc

What if you need to add a method to the provider interface, or modify the behaviour of some contract once a bug is discovered

All breaking changes

[analog badge]

Ok but that doesn't mean shit to a modder... If they need to use caps they have to use whatever API there is

Well the answer might be that we keep the bug if it's minor enough and really can't be fixed

[long ingot]

No that is not how this works tech

Bugs are fixed when they are reported

We are not taking the support burden for several months of a given bug

Too many users and players

[analog badge]

Orion, we DO NOT have the choice when it comes to modpack stability...

Making a BC late in a version's lifetime is much worse than dealing with a minor bug for some time

[long ingot]

Okey

[analog badge]

And usually we can find temporary workarounds that don't require BCs

[long ingot]

What about making the BC long

Like 75% to 80% of the update window

Were the first stable is released when mojang starts making pres

Or something like that

[analog badge]

That's still bad for modpacks then, if BCs can happen at any time

[long ingot]

So you are both arguing for a very small BC and only 1

Hmm

I mean

[analog badge]

Yes

[long ingot]

I see your side of things

I am just very afraid that we end up in the same PR slump that we did before

And that is really something I would like to prevent

Cause that put a very high amount of undue stress on us

That I would like to avoid if at all possible

[analog badge]

I think we should be honest with the community, BCs cannot be accepted past some point and that's it

[long ingot]

yeah

[analog badge]

Either the change is made non breaking and can go in ASAP once reviewed

[long ingot]

But the questiong becomes, when is that point?

[analog badge]

Or it has to wait for the next window

[long ingot]

I mean I am willing to concede that a BC Windows, a single one, is needed

Given that indeed we need stability for modpacks and modders

But, that being short, is something I really not sure about

IMHO it should be sufficiently long enough

For even the larger PRs to be accepted, reviewed, in production, tested by the community, and at least iterated on a couple of times

[analog badge]

I don't think that bugfixes usually need BCs

[long ingot]

Sadly especially for larger PRs and systems, I tend to disagree

The past has shown that we generally do not get it right in the first shots

Not even in the first couple of shots

[analog badge]

I get your point... From a forgedev perspective it's very annoying to maintain backwards compat, but we need a tradeoff between making our lives easier and making that if modders easier

[long ingot]

And I do not want to put that pressure on people either

It is okey to make mistakes

[analog badge]

Would the mistake not be noticed in the first few weeks?

[long ingot]

No I agree. Yes it is annoying, but we should fine a compromise

[tacit cloak]

IMO the breaking changes window should stay open as long as necessary to get the vanilla-imposed changes in, but not wait for "nice to have" additions or refactors

[long ingot]

That is gray though

[tacit cloak]

yes

always going to be

[long ingot]

Cause most larger refactors, like rendering, fluids etc, are all triggered by mojang, but they were nice to have mainly......

Under what category do they fall

Looking at it from the modder ecosystem

They sure as hell fall under vanilla-imposed changes, they were a direct concequence of the way mojang changed stuff

But they were not explicitly needed to make modded fluids for example

[tacit cloak]

well, if the vanilla changes removed/crippled an existing feature then that's a vanilla-imposed break

otherwise not

[long ingot]

Hmm

I would be willing to agree indeed

But it is still pretty vague

[tacit cloak]

yes it just means the team has to tag the issues/PRs accordingly

and if it takes a long time for people to get a PR working, it may be time to write off the feature and downgrade to "nice to have" for future version

[analog badge]

Well in other words we make a BC schedule based on what we think will make it in in reasonable time 😛

[tacit cloak]

yep

accounting for blockers

[long ingot]

So to summarize:

[tacit cloak]

like if mojang breaks worldgen it kinda has to be fixed

however long it takes

[long ingot]

1. We need a BC, we need the version number to indicate stability and we need to determine ourselves when the BC closes. In other words in this area, nothing changes.

2. Given that nothing changes with respect to 1. Does that means we should just stick to the existing versioning scheme (IMHO we should, with an option to maybe reset the major back to 1)

[analog badge]

What about snapshots?

[long ingot]

IMHO

[tacit cloak]

IMO we should preserve major so that we don't shoot ourselves in the feet if eg, forge dies next week and we have to take over maintaining 1.19.2

[long ingot]

We do not have the manpower for snapshots

So, this is cuzrrenty good enough

If we ever get the manpower for snaphots

We can rediscuss

[analog badge]

Ideally we would already find a solution rn

[long ingot]

And possibly mark them with some form of alpha indicator on the next majors .0.0 release

[analog badge]

Alpha indicator doesn't work well with maven ranges

[rapid totem]

i'd more side towards the end of talking about snapshot versions now, while we're planning things long-term

[long ingot]

It doers

[analog badge]

For example <49.0.0 includes 49.0.0-alpha

[long ingot]

2.0.0-alpha.0 comes before 2.0.0 if I remember

[analog badge]

Yes that's a problem

[woeful sphinx]

Maven versioning: 2.0.0-alpha.0 ∉ [2.0.0,)

Maven versioning: 50.0.45-alpha ∉ [49.0.0,50.0.0)

[long ingot]

Correct

So that would work perfectly

[analog badge]

How do modders declare their forge bounds then?

[long ingot]

[1.0.0,2.0.0)

I think

I need to check

[tacit cloak]

we just have to put the build number before the alpha tag

[woeful sphinx]

Maven versioning: 2.0.0-alpha.0 ∈ [1.0.0, 2.0.0)

[analog badge]

If you do that you accept 2.0.0-alpha

[long ingot]

Shit

[tacit cloak]

it's not semver-like but works

[analog badge]

That's why I suggested x.1.z for BC, x.0.z for snapshots and x.2.z for stable

[tacit cloak]

I don't see the point in reserving a digit for snapshots

[analog badge]

We'd already use it for stable vs BC

[tacit cloak]

yeah but it means that for as long as snapshots aren't happening, .0 remains unused

[woeful sphinx]

Maven versioning: 2.0.0-alpha.0 ∉ [1.0.0, 1]

[analog badge]

Yeah... not ideal I know

We just need to make sure that people can't run a mod compiled against 1.20.2 on a hypothetical 1.20.3 snapshot

(unless the mod author decided to allow that)

[woeful sphinx]

Maven versioning: 2.0.0-alpha.0 ∈ [1.0.0, 2.0.0-)

[analog badge]

Pfff

[woeful sphinx]

Maven versioning: 2.0.0-alpha.0 ∉ [1.0.0, 2.0.0-alpha)

[tacit cloak]

alpha is hardcoded before all - tags

-alpha, -beta, -<anything else>

[analog badge]

We could tell users they should use [48.0.0, 49.0.0-alpha)

[long ingot]

Yeah

That would work

[tacit cloak]

yeh that's basically the only sane thing if we use 49.0.0-alpha.<build>

[long ingot]

In gradle we could leverage rich versioning from now on out

[analog badge]

What is rich versioning?

[long ingot]

And implement it in such a way that users could even specify that they want a stable

[long ingot]

Google is your friend

It is a way of defining a version of a dependency that you need in a "semantic" way

[analog badge]

We should use "require", right?

(from https://docs.gradle.org/current/userguide/rich_versions.html)

I think we're good then

Last question is whether to restart with major version set to 1 or continue with major versions (next is 48)

[tacit cloak]

ew silly intervals :P

[analog badge]

Personally I'm in favor of keeping the current major cause there's no point in a restart IMO

We should change the modid to neoforge though

[analog badge]

(that's the French notation)

[tacit cloak]

yeah I think we used that in school too, but I really like () more for open instead of ][

like in my head

[1.0 .. [1.2

that would make sense

as "1.2 is part of the group beyond, not this"

[1.0, 1.2[ just doesn't feel right

[1.0,1.2) looks like it's getting close but not quite touching

which really fits the situation :p

anyhow

[delicate panther]

open vs closed set

[woeful sphinx]

Maven versioning: 20.2.1+1.alpha ∈ [20.2,21.0)

[long ingot]

You used plus

I think

[woeful sphinx]

Maven versioning: 20.2.1+1.alpha ∈ [20.2,20.3)

[delicate panther]

yes

plus is such a better separator

[long ingot]

Correct

But - actually has proper meaning

[delicate panther]

so does plus

[long ingot]

WHich is why it is perferred in the case of gradle

No

It is actually not relevant for the sorting

For example 20.2.0-alpha is before 20.2.0 while 20.2.0+alpha is considered equal or above

[delicate panther]

¯_(ツ)_/¯

[long ingot]

Hence me suggesting to use <major>.0.0-alpha.<snapshot>.<build> for versions for snapshots

[delicate panther]

i was just testing things

god that is so fucking ugly

[long ingot]

Just informing you 😄

[delicate panther]

and who's going to be release manager to tag all this shit?

[long ingot]

While <major>.<minor>.0-alpha can be used for BC preparation for the next release

[long ingot]

Most of this can be very well automated

[delicate panther]

because we're not going to be able to autobuild those versions

no, it can't

[long ingot]

Sure it can 😄

[delicate panther]

it can. but you're going to get into a fucking awful fuckup the first time you try and change something

[long ingot]

However, I don't have time to show you

I need runs to be online

So I can continue to port

[delicate panther]

of course

this is such a frustrating conversation

[long ingot]

It is

SC might need to make an executive decision

[delicate panther]

yes

[long ingot]

Based on an informed discussion in a voice call

[delicate panther]

but sadly, i don't think we're going to get agreement

[long ingot]

Probably not

For sure not with the rest of the community

[delicate panther]

everyone wants to DEEPLY overload the meaning of the version string

including you

[long ingot]

I know I do

[delicate panther]

look how much information you're trying to cram into the string

[long ingot]

Because I already leverage it for testing in NGNext

Specifically for Minecraft and NeoForm

I would like a version number with such information

So I can write dynamic tests into NGNext

That validate that change to NGNext work with the next Forge version 😄

Wihtout having to hardcode a forgeverison that is 😄

[delicate panther]

IMO we should first try and identify what and why we need certain info in the version string, rather than somewhere else, such as a metadata file

[long ingot]

Correct 😄

But

I am currently knee deep in gradle work

[delicate panther]

of course

[long ingot]

So my mind is not here enough

[delicate panther]

most of this should be very malleable

[long ingot]

I hope to have fixed enough of the build system

To be completely cache capable 😄

[delicate panther]

the only problem is, we can't do anything on 20.2 until we have agreement

[long ingot]

Damnit

10 more problems XD

[delicate panther]

LOL

[long ingot]

damnit

Fixed those 10

Okey

I have a solution for my last problems 😄

Just need to code it

Luckily mojang was very nice

And gave me a URL to download shit from

Instead of having to do dependency resolution 😄

Very nice

That is what i want to see!

Everything in parallel

Let's go!

[delicate panther]

noice

[long ingot]

This should now be compatible with the configuration cache 😄

And the build cache

Both locally and remote

[delicate panther]

cool

[long ingot]

Now I need to figure out runs 😄

Sadly setup time is not much faster

Because clean is terribly slow

But it is getting there

[remote apex]

we're definitiely not going to

a number of more than one person that votes is going to stall it immediately lol

the only way we get somewhere by.. tomorrow.. is by rolling a dice

[delicate panther]

that doesn't sound like a solution

that just sounds like a mess

[weary cliff]

problem with getting neoform to use parallel is that the gradle.properties needs to be gitignored which is where the property for parallel builds is specified

[delicate panther]

it's not gitignored?

[long ingot]

What are you talking about?

It is not

And NGNext has no problem running all of these in parallel

clean is still slow

But that is not neoform

NeoForm is run in as much parallel as NGNext can configure

[weary cliff]

I mean the NeoForm repo

[delicate panther]

k

[weary cliff]

not the use in NeoForge

[remote apex]

it is but we're not getting anywhere otherwise

[delicate panther]

i think the existing approach, flawed and borked as it is, has to win by default, not a diceroll

[tropic wave]

yeah, was just about to say this

if the existing system isn't actually breaking anything then we shouldn't make a change like this without a vote

and if there's not enough time left for a vote, then we should just stick with the existing system

[wooden sage]

Is there a reason you all can't do a proper vote?

[balmy ore]

we're still restarting at neo version 1.0.0 though?

[delicate panther]

we have a large number of choices, and most of them get 1 vote each luke

there's so many people who think that overloading the version number with so much semantic content..

[tacit cloak]

or we keep forge versioning which has been working fine for a long time and figure out snapshots if/when we decide to release them

[wooden sage]

I think giga or whoever it was that tried to split it up into different things had the right idea.

[remote apex]

we could definitely start with trying a maintainer vote and then a sc one but both of those are more likely to end in a draw than to not

[tacit cloak]

yeah it's pinned

[wooden sage]

Yeah that makes sense

[tropic wave]

we could keep the status quo for 1.20.2 and hold a vote to decide what to do with the versions for 1.21+

[tacit cloak]

can't keep up with proposals though XD

[tropic wave]

gonna need ranked-choice voting I think

[wooden sage]

The issue is that if you don't change it now, it's really not worth changing it later - because in theory there'll be more adoption by then

[tropic wave]

the status quo is... what people have already adopted for years

[wooden sage]

This isn't a bad idea. Makes it less likely to end up with a draw

[delicate panther]

our choice now is essentially fixed in time for the next few years

[wooden sage]

Yes but they're changing one way or another because they're switching to neoforge from forge

So any other changes to artifact naming - this is the time to make them, if you ever do

[tacit cloak]

as I said before, I am ok with all the semver-like options. I just want neo to pick one and change the modid so it stops colliding with forge :p

[balmy ore]

okay, so we're saying keep the same versioning system we have been using.
But we'll still start at 1.0.0 of Neo? Right?

[tacit cloak]

my preference though, is 48.0-alpha.1 for breaking changes, no restart. but I'm ok with restarting if people prefer it

[wooden sage]

Well, that means basically that neoforge decides not to ever touch stuff before 1.20.2

Or to use different versioning for that

[delicate panther]

any touching previous versions will maintain the existing number scheme luke

don't mix shit up

[wooden sage]

Would it necessarily?

[delicate panther]

we're not going to release neo 0.9 for 19.2 or anythign dumb like that

well, if we don't, then who the fuck is going to use us?

[tacit cloak]

and I'm ok with 48.0.1-alpha
and 48.0.1-alpha.234
and 48.0.1 (0 means breaking changes)

[wooden sage]

Right but my point is that either, not restarting the version, or using the MC version in the version, avoid this issue

[analog badge]

I wouldn't mind if someone made an executive decision so that we could move on

[tacit cloak]

and their corresponding restart-at-1.0

[delicate panther]

i would love to, but that's not going to happen tech

because any decision will necessarily annoy a large subset

because this is the colour of the bikeshed so everyone understands it, and it's important

[wooden sage]

If any sort of "executive decision" happens it would have to be a steering council decision, not a single person, anyways, right?

[analog badge]

SC could defer to a single person technically

[tacit cloak]

if there's no decision, what's the fallback? keep forge versioning as-is?

[analog badge]

I'm just tired of this discussion

[tacit cloak]

cos that works for me lol

[delicate panther]

that's the point giga

[balmy ore]

If no consensus can be reached, it seems reasonable to have the council step in and say "We're keeping the versionins system as is"

[analog badge]

Keeping the current versioning works fine for me too

[delicate panther]

but then we'll have 48 neo and 48 forge

oooof

[boreal blade]

keeping forge versioning but restarting at 1 seems like it would work too

[tacit cloak]

yes but different modid and artifact so no conflicts

[wooden sage]

Okay, I've seen why a vote seems to be difficult to set up without a lot of pain. Why not just have a steering council only vote on versioning?

[delicate panther]

except luke thinks we need to not do that

[boreal blade]

though it kills the backporting idea a little

[delicate panther]

what does backporting even mean?

[analog badge]

That doesn't matter, does it?

[tacit cloak]

if we want to start supporting 1.19.2 we can't use version -2

[delicate panther]

you think there's any desire to uptake neo, in NEW form, with new version numbers, on 19.2 f.e.?

[analog badge]

What we need to do is change the modid to neoforge

[delicate panther]

but any release for 19.2 would use the legacy forge numbers surely?

[wooden sage]

It means "any possible scenario where neoforge wants to release stuff for versions older than 1.20.2, and not step on forge versioning". It's unlikely, yes, but ruling it out entirely seems like a bad idea in general?