#Versioning

1 messages · Page 2 of 1

tacit cloak
#

like

#

neoforge:2.3.4+mc1.21

quaint oak
#

Another point: future goals of separating loader and neoforge-api itself

#

If this starts going down the fabric route (Which users seem to be fine with as far as versioning goes) - it's full semver over there

tacit cloak
#

yeah I have no opinions about it because I personally would prefer neoforge to continue being the monolithic option

quaint oak
#

I am VERY much a baremetal kind of programmer and want to know breaking changes first. Semver is important af for that

tacit cloak
#

I'm a high-level programmer, I want things to be as thought-free as possible, and having a monotonic versioning means I can very easily specify a breaking changes window without worrying
[2.0,3.0) will never have the possibility of me forgetting to update the version range after bumping the mc version

#

but if it's back to 1.0 every major version I may forget to reset the minimum version and releasea mod with [1.0.453,) that actually would have worked from 1.0

quaint oak
#

Imagine a future scenario, after a user installed fancymodloader-3:

- platform-mods
  - neoforge-core-2.1.0.jar
  - neoforge-events-1.0.0.jar
  - somecoremods-mixins-12.3.0.jar
- mods
  - compactmachines-26.0.0.jar
quaint oak
#

Also.. we could technically move the minimum Neo version out of manual assignment. It gets added to META-INF on build, with the range being chosen from [<targeted NEO dependency>, NEO-version-major + 1)

#

Then nobody could forget. Ever. It'd enforce that you only bump Neo version in dev when you ACTUALLY need something

#

So META-INF/MANIFEST.MF:

Neoforge-Build-Version: 1.2.0
thorn prawn
#

Mc version does not make sense in the artifact id at all

#

I oppose that definitely

#

I guess having the mc at the start of the version would be bad for if we ever get froge up and running and publishing

#

so personally, we should follow fabric in that regard

#

having it as a suffix

#

this means keeping the major version sorted nicely would be important

#

Personally I think bumping the major version every single mc release is the way to go

#

And we can prematurely bump it for snapshots

quiet jewel
#

to clarify: as I understand it that would result in significant gaps in the major versions for each MC release, is that intended?

thorn prawn
#

mc release is not a snapshot

#

you literally just said mc release in the way I intended

quaint oak
#

So, if we're going the route of "one breaking change window, try to follow semver", can we at least kill the .1 system?

50.0.0-beta.1 -> 50.0.0-beta.420 = rapid breaking changes
50.0.0 = stable
50.1.0 = new feature hype

etc

thorn prawn
#

all I mean is when working on snapshots you bump the major to indicate it's for the next mc release

quiet jewel
#

oh, so there is not a bump per snapshot

thorn prawn
#

there is for the first snapshot of a release cycle

#

In my proposal at least

quiet jewel
#

but not for any further snapshots till a release

thorn prawn
#

yes

quiet jewel
#

got it, that makes sense

thorn prawn
#

why not just allow breaking changes at any point but bump the major

#

like how normal semver works

quaint oak
#

We just had a huge discussion on that.. people apparently want a single BC window

thorn prawn
#

meh idrc either way

#

I would argue we need to keep the major starting at 47 like it is now

#

So that we have the option to backport in the future if we want

tacit cloak
#

oops ping

#

holy shit the brainfart

quaint oak
#

Blah

#

Then you'd need the MC-M.m.b format

#

Or a separate version check for just MC

tacit cloak
#

or at least that's what someone said

#

I didn't actually verify the claim

#

and assumed they were stating a fact and not just an assumption

wooden sage
#

This is a fact about how semver works, and about how maven version ranges work

#

Versions with metadata come before the same version without it

#

Which makes sense, but causes issues with maven version ranges

#

The version ranges that fabric uses have some ways around this I believe, but yeah, it's not great

quiet jewel
#

can we add support for the 4.x style syntax?

thorn prawn
#

Link?

wooden sage
#

4.+ to depend on any version in the 4 major version

#

Like you can do in gradle dependencies

#

Or 4.x for the same, like fabric, I believe, does?

#

That's not a bad idea actually

#

Let's us use a proper semver version scheme

thorn prawn
#

I think they mean maven 4.x or maybe the 4 is just an example

#

cuz afaik we use something something apache 3.x

wooden sage
#

Because people would just use 4.+ instead of [4.0.0, 5.0.0)` and wouldn't catch those prerelease versions

wooden sage
#

Though I could be wrong

quiet jewel
#

it's an example yes

#

[4.0.0, 5.0.0) is overly verbose compared to 4.x

wooden sage
#

Personally I'd prefer 4.+ over 4.x` as the former is what gradle uses

quiet jewel
#

sure, not picky about the character

wooden sage
#

4.+ excludes those pesky prereleases

remote apex
thorn prawn
#

that's a bit strong

tacit cloak
#

no it's not strong

#

we are actively overlapping with forge

#

but in binary incompatible ways

#

that's the worst possible situation

thorn prawn
#

so backporting to older versions will be literally impossible

tacit cloak
#

no, we still have the aliasing

#

neoforge:1.0 can expose forge:47.1.3 as a compatible modid/version pair

#

so in summary my opinions:

  • neoforge-1.21:1.0.43 -> neoforge-1.22:1.0.0 -- 🤷‍♂️
  • neoforge-1.21:1.0.43 -> neoforge-1.22:2.0.0 -- ✅✅
  • neoforge:1.0.43+mc1.21 -> neoforge:2.0.0+mc1.22 ✅
  • neoforge:1.0.43 -> neoforge:2.0.0 😕 (I'm ok with it as a developer but the downloaded files REALLY need the mc version for the user benefit)
  • neoforge:1.21.0-1.0.43 -> 1.22.0-1.0.0 🤷‍♂️
  • neoforge:1.21.0-1.0.43 -> 1.22.0-2.0.0 🤷‍♂️✅
  • neoforge:1.21.0.43 -> 1.22.0.0 ⛔ (please no anything but this)
wooden sage
#

Personally, if we take embeddedt's suggestion of allowing 2.+ version ranges, I'd go for a simple semver system with -alpha.1 etc. for snapshots and -beta.1 etc. for BC window stuff

quiet jewel
#

could solve the issue of not knowing the MC version with a simple page listing the mappings, e.g. 1.0 -> 1.20, 2.0 -> 1.21, etc

wooden sage
tacit cloak
#

I included it because it was nano's suggestion

#

the 🤷‍♂️ means "not a fan"

wooden sage
#

People need to depend on neoforge, and that means having version formats that are stable over MC versions

#

Even if the artifact ID isn't

quaint oak
#

But Neo increments major every MC version anyway..

wooden sage
#

Because they need to shove something in the mods.toml

tacit cloak
#

if you see above, I agree

wooden sage
quaint oak
#

I still argue we can get rid of the manual min version check in mods.toml, in favor of build-time metadata

tacit cloak
#

build-time min version is a big no from me

wooden sage
#

And forge shouldn't be "special" in this regard. It's a mod dependency like any other

tacit cloak
#

I like to build in the newest version available to make sure nothing broke, but I specify the minimum I'm compatible with

long ingot
#

And break my support range

#

So I don't think that is a good idea

wooden sage
#

Given that in some cases I build on a newer version, but work on versions for previous MC versions...

#

Yeah no can we please not do that

quaint oak
#

If we keep one breaking change and major per MC, it's easy. "Compiled with Neo 48.1.36, requires at least 48.1"

tacit cloak
#

no, just because a breaking change EXISTS

#

doesn't mean it affects my mod

wooden sage
quaint oak
#

Okay, argument made

#

Can't have a complete discussion without throwing out ideas and finding what definitely WILL break workflows

wooden sage
#

Also, I highly dislike the idea of special casing forge dependencies compared to other mod deps

wooden sage
# quaint oak Can't have a complete discussion without throwing out ideas and finding what def...

I mean, that's the point of a discussion, yes, to figure out which ideas are infeasible just due to how stuff works. And always depending on the version present at build time is both infeasible, as that's not how lots of people write mods, and there's no good reason they shouldn't be able to write them the way they do, and also generally ugly, as it means you special case neoforge dependencies compared to other dependencies

#

You'd still need to specify the top end of the version range somewhere anyways

quaint oak
#

I think the larger problem here is not being able to specify multiple MC versions cleaner - it's coupling MC version and Neo version too closely. I feel like Fabric really had the right idea by versioning areas of changes

#

So you could say "MC 1.18 - 1.20.1" in one range, and something like "dimensions 1.0" in another

wooden sage
#

Right but that only makes sense with Fabric's super long guarantees of no BCs. For forge, the BC windows are coupled to MC versions

#

And we should bump the forge major version on BCs, no matter what

#

When I depend on forge versions, I am also depending on MC versions, for that reason

analog badge
#

Current system works better than most people would like to admit, IMO

#

Just remove the concept of latest and recommended builds, make x.0.y unstable and x.1.y stable

#

We can spend hours discussing a new system that is 10x as bureaucratic and complicated, or just keep the system that works pretty damn well

#

Also, no reason to reset the version IMO... I don't expect Forge to continue to exist anyway

tacit cloak
#

I don't agree with that assumption

lethal scarab
#

I can get behind that, but something similar was discussed earlier and my problem with it also applies to this

tacit cloak
#

I mean I don't know how long forge will continue to exist for

#

but I think it's in bad faith to use the same modid because "it won't exist in the future"

#

if we change modid but keep the version that I don't care about

analog badge
#

I don't give a damn, really

lethal scarab
analog badge
#

Yeah sure modid change but keep version is good

tacit cloak
#

but I do think it can be confusing for the users while forge exists

#

which is something I'd like to avoid

analog badge
#

I don't expect that to be significant

#

Modpacks will have to use Neo and so users too

tacit cloak
#

IMO the download site, right now, should be saying "NeoForge for 1.20.1 version 1.0.45 (Forge 47.1.3)"

lethal scarab
#

Gonna be honest, while I'm aware of the actual situation, there's probably a lot of confused users looking for a forge build that doesn't exist yet and also a bunch who think having the same modId but higher version than actual forge is a malicious attempt to get people to switch to neoforge

analog badge
#

Idk, I'm annoyed at the message spam for something that looks like a non-issue to me

tacit cloak
#

it's a community discussion, there's diferring opinions, the whole point is to give people a chance to be heard

#

that said, this discussion has probably lasted far too long already

#

there should have been a deadline for proposals and a vote if more than one proposal fit the requirements

analog badge
#

It sounds like something that the SC should decide once and for all

#

Make a list of potential issues and proposals, then pick something that's simple and that works

#

(or so I would approach it, at least)

#

Personally:

  • One release per commit is extremely nice for automation and has worked well.
  • RBs don't make sense, so only use 0 for unstable and 1 for stable.
  • Keep same major version as Forge cause resetting it is awkward and useless
  • Maybe change modid (or maybe not)
wooden sage
#

I'd say we should try to follow semver because honestly it's easy to. And I think the .1/.0 being the only things for that middle version shouldn't stick around - it's needlessly confusing

#

And it also doesn't describe what's going on

tacit cloak
#

there's no realistic way to follow semver

wooden sage
#

Version numbers should describe at a glance what we're looking at

tacit cloak
#

we can't bump minor every time we add something

wooden sage
tropic wave
#

I don't think there's any reason to follow semver

wooden sage
#

Bumping the minor version with new features, and patch for bug fixes, is pretty easy

tacit cloak
#

also, IMO having the 0/1+ thing is a lot more meaningful for at a glance knowing what we are looking at

wooden sage
#

That's in my opinion a lot more informative

#

And allows you to follow the same pattern for snapshot releases if those ever exist

stoic sedge
tropic wave
tacit cloak
#

haven't we established that 1.0.0-beta doesn't work with maven versioning?

tacit cloak
tropic wave
wooden sage
tacit cloak
#

to anyone from the general public major version = big change, minor version = small change, patch version = very small change

#

there's no implicit meaning beyond that except to devs

stoic sedge
#

Then how would you read the version of a new project you haven’t seen before? What assumption would you make about major.minor.patch numbers?

wooden sage
tacit cloak
#

none at all, I would see a version and take it

tropic wave
tacit cloak
#

at most, if I see 3.0 I would think "oh this project has gone through two major refactorings"

stoic sedge
wooden sage
#

Basically, it should be obvious at a glance, at a version number in the breaking change window, that "this could break whenever". And it should be obvious at a glance at something post that window that "this won't break till ________". Whatever system you end up on has to do that. The current .0/.1 system does not, unless you already have a good understanding of how the forge RB system works

#

Whether or not you end up following strict semver, something more semver like will help address that issue, in my opinion

#

But the issue needs addressed somehow

#

Using a prerelease version for stuff in the BC window makes it obvious that it can break

stoic sedge
#

On other hand, recommended build isn’t that important to know at a glance. Once it happens, you either know that version already or will use latest always

tropic wave
#

The current .0/.1 system does not, unless you already have a good understanding of how the forge RB system works
this is true regardless of what semantics the version has

wooden sage
#

And following semver conventions - at least with the major version representing breaking changes - ensures the second part

tacit cloak
#

yes, I honestly believe that the ideal system would have the minor version bump any time there's meaningful changes beyond small bugfixes
such that the patch version changing becomes "if you aren't crashing no need to update"
the minor version is "if you want new features update"
and the major version is "if you update you have to update all your mods too"
I just think bumping minor for additions is an unreasonable maintenance burden for the team

wooden sage
lethal scarab
#

I wonder how many messages have been posted here by now...

wooden sage
stoic sedge
remote apex
tacit cloak
#

the closest I can imagine is a label on the PR which is used by CI on merge

wooden sage
#

We do it for GroovyMC projects

tacit cloak
#

but that requires that the maintainers make 100% certain that th e right label is applied before merging

supple panther
wooden sage
#

Based on a prefix on commit names

tacit cloak
#

and direct pushing becomes strictly prohibited

supple panther
#

might require multiple synchronous release branches

wooden sage
tacit cloak
#

as I said: maintenance burden

lethal scarab
#

SimpleCI is a terrible system in that you don't know which build corresponds to what and builds fail if git isn't cloned properly

wooden sage
wooden sage
lethal scarab
#

So then we end up shoving commits inside of jars so there's at least some way to tell if you're desperate, which kills caching and worsens build performance

wooden sage
#

Tags make stuff more obvious

#

And yeah, we should probably be tagging releases

#

(we as in GroovyMC)

#

(and I'll be setting that up for the projects I maintain soon enough)

lethal scarab
#

It would be so much simpler if it just read the commit title and used that as the version if it starts with a v

tacit cloak
#

the forge approach is simple and almost fool-proof: tags only need to be created when an explicit decision is made to bump versions, CI takes care of the rest.
no "before merge" checklists to worry about, no beginner mistakes to worry about, no delaying merging because the team people are too busy and adding more red tape has made it too much effort to continue helping

lethal scarab
#

Commit "v1.1.2" publishes version 1.1.2. So much simpler

tacit cloak
#

horribly error-prone

#

oops I was in a hurry and typoed v11.2

wooden sage
lethal scarab
#

The existing Forge versioning works fine

tacit cloak
lethal scarab
#

You would have a tag every commit if you were tagging for every build...

wooden sage
tacit cloak
#

no

#

never

#

the patch version is calculated by git commit list

wooden sage
#

Right, which makes finding a commit from a version painful

tacit cloak
#

patch = number of commits since newest annotated tag in the branch

wooden sage
#

That's what SimpleCI does too

stoic sedge
#

While I’m not a fan of the needing of prior knowledge for minor version meaning in forge, seems better to just stick with that versioning for Neo

#

Just have it explained somewhere like doc or on versions page

tacit cloak
#

also we could easily include the commit hash in the changelog

#

it's kinda silly that we don't

#

47.1.120(47f72a765bc):
changes here

wooden sage
lethal scarab
#

Because we have the PR number which links to the commit hash

#

But I do miss having PR authors listed in changelogs like the good old days. Was always nice seeing from a glance who worked on a PR without having to manually look up all the PR numbers

tropic wave
thorn prawn
#

It has?

#

I forgot what we ended up with

stoic sedge
lethal scarab
#

Nope, orion changed it during the move to teamcity and that was that

tropic wave
analog badge
#

PR and self-merge should be the norm

lethal scarab
#

I recall Curle saying in the private channel that we don't have triage anymore, people can merge directly

analog badge
#

For the toolchain stuff like NG and Neoform it doesn't really matter

lethal scarab
#

Presumably someone else still has to merge for obvious reasons though

wooden sage
remote apex
#

there's no requirement for the merge to happen by someone else tho

lethal scarab
#

So make a PR, forget to test it, merge it yourself straight away and we're screwed... Got it

lethal scarab
remote apex
#

no requirement mind you, as in, there's no github rule unlike the PR enforcement. there's still the informal "let someone else do it"

wooden sage
thorn prawn
#

org admins can also bypass everything anyways

remote apex
#

yes and that's stupid, I'm still not sure why we disabled the rule for org owner...

#

it means an org owner can push directly which is bad for.. multiple obvious reasons (security, auditability)

lethal scarab
tacit cloak
#

there's I think three concerns wrt the choice of versioning. in no particular order:

  1. how will the average user know which mc version a random installer file in their downloads folder is for
  2. how will users/devs know if a version is within breaking changes window and they have to expect future breakage when choosing to use it
  3. how will users know if it's safe to update from their existing version to a new one

wrt the current forge versioning:

  1. no issue, mc version is part of the filename
  2. no issue, breaking changes are only allowed if minor is 0
  3. no issue, versions before minor=1 need to be tested before updating, versions after minor=1 should continue working without introducing new incompatibilities
    I think the existing forge scheme is reasonably clear on all 3. the only maybe-concern it has is that the maven version includes the mc version, but the internal version does not. is this a real issue? I don't particularly think so, it has worked fine for 10 years.

considering all the concerns expressed here, my current opinion (yes it will fluctuate I'm not screaming from any hill):

  • reset version along with new modid, to celebrate the culmination of the forking effort (seems like the version and modid/artifact is the only remaining thing where neoforge hasn't rebranded, because the aliasing system doesn't exist yet)
  • continue having the mc version prefixed in the maven artifact
  • continue excluding the mc version from the mods.toml version string -- we can use the minecraft dependency for mc range checks
  • major = new breaking changes period, whatever prompts us to have one
  • minor = added new major feature/API -- this depends on the team choosing to take on this additional burden. I would still have .0 reserved for breaking changes period regardless
  • patch = autocounting via git
remote apex
#

if there isn't a formal vote there's no decision

lethal scarab
#

Note that I'm a moderator so I might be unable to see a special maintainer voting channel or the like

lethal scarab
remote apex
#

iirc said discussion was promoted by github for mobile not displaying rules correctly..?

#

and thats why the enforcement for another member approval was removed

#

it wasn't a decision per se, it was a UX and accessibility issue

wooden sage
# tacit cloak there's I think three concerns wrt the choice of versioning. in no particular or...

I'm going to debate your answer to point 2. There is an issue because it's not at all intuitive that "minor version of 0" should mean "BC window". That's kinda random when we've got stuff like prerelease versions meant for that. I'd also debate on 3 - there is not issue if you know the rules and the rules aren't obvious. If we switched to something semver like with prereleases, it would be far more obvious how it works

lethal scarab
#

Every time I try making a PR to neoforged since the switch to main, the github for desktop app has problems finding the repo, especially the preview PR function

wooden sage
#

The GitHub for desktop app sucks in general

lethal scarab
#

So you can argue the same ux point for not changing it

lethal scarab
wooden sage
#

So not strict semver

#

But more intuitive to someone who doesn't know neoforge versioning madness than the current scheme

remote apex
lethal scarab
#

And the CoC notice showed up fine today on master branch repos when doing my first PR to some new repos in the forge project

remote apex
#

and in any case that was a decision that had to be done when the org was created, so there were exactly 4 people to weigh in on it

lethal scarab
#

Always a clean clone for the neo stuff. It's a pita for the sake of avoiding correct usage of a word

remote apex
#

I've been using gh desktop since forever and my personal repos use main so /shrug

lethal scarab
#

So your point about rules not showing up without using main is not only incorrect, it's irrelevant

remote apex
#

what point

lethal scarab
remote apex
#

I'm talking about actual rules, not the CoC

#

branch rulesets, the only thing on github's side that can enforce an approval from another remember before merging

#

those rules would not show up in the github mobile app when a PR is to be merged, it would just say "PR can't be merged" without mentioning why

lethal scarab
#

Alright, thank you for clarifying

tacit cloak
#

someone suggested even/odd versioning

#

that is probably even more confusing for the average user

#

(that is, all odd versions are prerelease, all even are stable -- or the other way around)

lethal scarab
#

Are you sure an exclusive upper maven version range would include beta versions of said upper range?

tacit cloak
#

I haven't verified myself, but it seems to be something people say is true

#

of course everyone could be wrong I guess

lethal scarab
#

That sounds more like [47,48] to me

#

Worth checking

tacit cloak
#

well the thinking is that [47,48) does "if version >= 47 && version < 48"

#

and 48-beta is < 48

#

if version ranges are compared like that, it makea sense that it would be true

lethal scarab
#

Yeah that makes sense, although I would hope the version checking logic would factor in betas and the like

tacit cloak
#

yeah I still don't know if, IMO, [48,) should include betas for 48. in a way I think it should

#

48.0.0-beta should compare as a version between 48.0 and 48.0.0

lethal scarab
#

Both including and excluding makes sense depending on different logic

#

Whatever maven actually does is probably the expected behaviour

remote apex
#

alphas and betas are intentionally lower than the "release" version

#

so [48, should not include betas, rcs or alphas

tacit cloak
#

the issue is [,48)

#

does that include the alphas and betas?

#

because by any meaningful sense of version range, it should not

lethal scarab
tacit cloak
#

48.0-alpha.1 should NOT compare as inside [47,48)

remote apex
#

48 is 48.0.0 > 48.0.0-alpha

#

so if it's exclusive 48 than everything lower should be included

tacit cloak
#

yes I understand the logic

#

I'm saying that this logic, while it makes sense, it does not represent how we think of versions

#

so I am wondering if our mods.toml version checking actually does that

remote apex
#

I need to implement a mavencompare command in camelot lol

#

@rapid totem if you're bored ^

tacit cloak
#

OH right I can test give me a second

lethal scarab
#

Not including alphas and betas in <=48 also makes sense for different reasons

tacit cloak
#

I was thinking I would have to create a dummy mod with version and shit

lethal scarab
#

As I said, whatever forge actually does is what matters to us

tacit cloak
#

but I don't I just need the Expression Evaluator in intellij heh

lethal scarab
#

lowcode mods

remote apex
#

or just open a random Java project, add the apache maven versioning library and just test :P

#

defaultversion is the name of the class I believe

#

or comparableversion, one of those

tacit cloak
#

VersionRange.createFromVersionSpec("[47,48)").containsVersion(new DefaultArtifactVersion("48.0.0-beta.1"))
result = true
VersionRange.createFromVersionSpec("[47,48)").containsVersion(new DefaultArtifactVersion("48.0.0"))
result = false

#

there we go

#

confirmed, maven versioning is trash

wooden sage
lethal scarab
#

Semver parsing is painful though

tacit cloak
#

luke: the issue is if I want to depend on [1.3.5,2.0)

#

1.+ syntax cannot represent that properly

wooden sage
remote apex
wooden sage
remote apex
wooden sage
#

Where 2.0- is below all 2.0 prereleases

remote apex
#

not sure if that's semver spec or just fabric sugar

tacit cloak
tacit cloak
wooden sage
tacit cloak
#

to YOU

lethal scarab
#

I'm with giga here

wooden sage
#

To anyone. It's a _pre_release

tacit cloak
#

because you have learned of it

wooden sage
#

Think about it: 1.20.1-rc.1 comes before 1.20.1

tacit cloak
#

common sense would say that the moment the major version became 48, it was excluded from that range

wooden sage
#

But regardless, this particular issue is one fabric solved ages ago

#

By not using maven version ranges

lethal scarab
#

While it makes sense either way you look at it, you wouldn't expect a variant of version 2 to be included when you say anything upto but excluding version 2

wooden sage
#

Because maven version ranges suck

#

And expect two well defined endpoints

#

Which is the issue here because the latter endpoint isn't well defined

lethal scarab
#

Maven version ranges are easy to parse though which is nice

wooden sage
#

Or rather it is to us but can't be expressed in a maven version range

lethal scarab
#

The semver handling in mods.groovy v2 is a lot simpler than v1, but it's still a lot more complicated than maven

wooden sage
remote apex
lethal scarab
#

First thing I see in the readme

image0.jpg
tacit cloak
#

but anyhow

#

if anything is bikeshedding, this is

#

the matter is still the same

lethal scarab
#

Maty I spent days trying to use libs for this before settling on doing it myself. Maybe for comparisons you can get away with it but for full parsing and conversion it's not a simple "hurr durr just import this random lib I found that says it's experimental"

tacit cloak
#

if we continue using maven versioning

#

then I cannot vote in favor of having beta tags in the version

#

I am happy with beta tags in the version if we move away from maven version ranges -- whatever the alternative looks like

#

otherwise even if it's uglier semantically, I prefer .0 = breaking changes, .1+ = no breaking changes

remote apex
# lethal scarab First thing I see in the readme

that's irrelevant, the library has been with a major 0 since 2015, it is used by over 700 people (not projects, which is more), and in any case we don't need api stability for the library that checks the version range

lethal scarab
#

Most notably the most popular still maintained semver lib for java has a recent issue opened for testing basic version range formats

wooden sage
#

The trailing zeros better dang well just be visual preference

#

Cause if not that's even more confusing

tacit cloak
#

to me, the beta tag applies to the version component it's attached to

#

48.0.0-beta is ["48", "0", "0-beta"]

remote apex
#

@nocturne moat what does fabric use for semver testing

lethal scarab
tacit cloak
#

it's still in the 48.0 family, just happens that the patch version is a pseudo-number that compares less than 0

wooden sage
#

...sure. But as 48 is 48.0.0, it's still less than 48

tacit cloak
#

"48 is 48.0.0" I disagree with that assumption

#

48 is <= 48.0.0 but not == 48.0.0

wooden sage
#

Well it's a reasonable assumption coming from knowing nothing about versions. It's how normal numbers work after all. 48=48.0

tacit cloak
#

in my mind.

#

but anyhow my thoughts on versioning are way offtopic

#

and we have spammed this discussion well enough

#

and they do not affect the choice of versions

wooden sage
#

But yeah, this is a solved problem. The sort of version ranges fabric uses get around the limitations of maven ones by not requiring well defined end points

tacit cloak
#

because I would love to have beta tags

#

I just think they are not compatible with using maven version ranges

remote apex
tacit cloak
#

so
if maven version ranges - 🚫 beta tags
if other library that doesn't share the same issue - ✅ beta tags

wooden sage
lethal scarab
tacit cloak
#

no like forge is using org.apache.maven.artifact.versioning lol

#

literally maven versions

wooden sage
tacit cloak
#

it's not about the format, it's about how the library interprets the string

wooden sage
#

But okay then, there's a question: is moving either away from maven version ranges, or to a slightly modified version, feasible and something you'd want to do?

lethal scarab
#

Take 5mins to actually look into this rather than assuming it's as simple as importing a random library and making a minor bugfix here or there. From the guy who spent days trying libs and then manual parsing very recently

wooden sage
tacit cloak
#

since I'm not really active as a maintainer right now, my vote here is 90% from the point of view of a mod developer
and the other 10% is not wanting neoforge to fall into the "red tape trap" and delay merging PRs because the team finds it too much of a chore to go through the checklist

lethal scarab
wooden sage
#

From the perspective of not at all a maintainer but a mod developer - the current system really sucks but whatever

lethal scarab
#

I think mine does too actually lol

wooden sage
#

Otherwise I'd have just done what fabric did

tacit cloak
#

huh, I really like the forge system, I just look at the number I have in my build.gradle, and copy it to the mods.toml :P

wooden sage
#

Which was way simpler

tacit cloak
#

and I know that the next major = 100% chance my mod won't work anymore

wooden sage
lethal scarab
#

My point is more that maty throwing a random Google search result link of a lib to say that it's easy is really lazy

wooden sage
#

Or rather, I do but it wasn't obvious

lethal scarab
#

Especially when it doesn't take long to see that it's marked as experimental and has known issues related to beta parsing

wooden sage
lethal scarab
#

Those are entire mod loaders harold

tacit cloak
#

anyhow I have stated my current opinions which are predicated on what we do wrt version range annoyances. feel free to poke me again if there's any meaningful decision that may impact my opinions :P

wooden sage
#

I'd worry less about how feasible implementing that is and more about whether neoforge wants to bother shipping it's own system for it

#

Because it's obvious that it's feasible

#

Because yeah, other modloaders do it

lethal scarab
#

If people wanna go down that road then go ahead

#

But it's not an easy feat compared to maven version parsing

#

Sure you've done it before, but with a lot of long regex queries

#

To be clear I'm not against adopting semver, I'm merely pointing out that it's harder to implement properly than maven

#

And that suggesting it's as easy as importing the first random lib you find on Google is ignorant

nocturne moat
lethal scarab
#

Semver version range parsing

nocturne moat
#

We have a custom thing for it

#

It's roughly based on the node js library "semver"

analog badge
#

Fabric is 0ver anyway

wooden sage
#

That's not really relevant here though

stoic sedge
#

and not nice to say to modmuss directly

lethal scarab
#

Fabric is 0-ver, latest is 0.87 or something. But not sure if he meant that or "over"

#

I haven't touched modding in general for a while so I wouldn't know

nocturne moat
stoic sedge
#

then my bad

nocturne moat
#

It's not your fault at all for not knowing. 😂

analog badge
#

Yes it's zero ver lol, not "over"

lethal scarab
#

From the about page thinkies

ZeroVer is satire, please do not use it. We sincerely hope no project release schedules were harmed as a result of this humble attempt at programmer humor.

boreal blade
#

So in my experience NuGet has pretty good version handling and parsing, maybe it would be worth looking into how it parses versions to base a custom solution on?

remote apex
silent ginkgo
#

👀

quaint oak
#

Oh no, fancy math symbols

ashen heart
#

∉ means not element of

quaint oak
rapid totem
#

smh, not using actual words

quaint oak
#

1.20.2-beta vs. [1.20.1,1.20.2) ?

rapid totem
#

@remote apex

ashen heart
remote apex
silent ginkgo
ashen heart
#

since maven versioning only cares about ordering and not compatibility

rapid totem
#

too busy with regexes

remote apex
tacit cloak
#

oh nice it ignores tags? that's good

#

that means 1.0.0+mc1.20.2 is an option

remote apex
#

that's semver

tacit cloak
#

oh didn't look at the command facepalm

woeful sphinxBOT
#

1.0.0+a < 1.0.0+b

tacit cloak
#

sad

#

well it's not horrible actually

ashen heart
#

can we convert the maven ranges from the mods.toml to semver ranges internally and use semver from there on?

woeful sphinxBOT
#

2.0.0+alpha.1 ∉ [1.0.0,2.0.0)

tacit cloak
#

but

woeful sphinxBOT
#

2.0.0+alpha.1 > 2.0.0

silent ginkgo
woeful sphinxBOT
#

2.0.0-alpha.1 ∈ [1.0.0,2.0.0)

ashen heart
woeful sphinxBOT
#

2.0.0-alpha.1 ∈ [1.0.0,2)

silent ginkgo
#

Why

boreal blade
#

So, has floating versions like this been considered? This could allow neoforge to be versioned something like 193.1.x where 193 = MC 19.3, 1 = first release for 19.3, x = build/bugfix/etc

Screenshot_20230906_140446.png
#

It also allows the use of metadata to indicate prerelease versions, which mods won't pick up by default unless they opt-in

ashen heart
#

what about snapshots?

boreal blade
#

I imagine they would work using the next available minecraft version with release metadata to indicate which snapshot

#

so, 194.1.x-snapshot.snapver

ashen heart
#

but we don't know if a snapshot is for a minor or a major

boreal blade
#

we don't, but snapshots tend to not last very long either, and I imagine they're mostly used for development anyway

ashen heart
#

not if we get froge up and running

boreal blade
#

alternatively, you could keep them on the same version, so 193.1.x-snapshot.snapver for a snapshot ahead of 1.19.3

#

since it would be the "next release" you could also possibly bump the second digit too

#

it's possible that multiple mc versions could match up but I can't think of any off hand where that would be the case, at least with two digits

ashen heart
#

but take 1.7.10 for example that would be 710 which is higher that 193

boreal blade
#

Okay, but if we're pinning users to 193.1.* then that's not an issue; it's only an issue if you're asking for the * version, which you shouldn't

boreal blade
#

However, I'm operating under the assumption that neoforge won't backport so it shouldn't be an issue for the most part

rapid totem
#

making assumptions, are we?

boreal blade
#

And if that really is a dealbreaker, the versioning could be mcver.mcver.neover-snapshot.snapver, so for example 20.3.1 for the first release for 1.20.3, or 20.3.2-snapshot.23w35a for snapshot 23w35a against the latest version 20.3

#

The biggest issue with that is that you've gotten rid of the biggest opportunity to use floating versions

#

so I can't say that I'm compatible with any bugfix versions of neoforge for a given minecraft version

ashen heart
#

there was an argument made to not use the mc version in the actual neo version but only in the meta to have it in the download filename

boreal blade
#

I suppose that works

ashen heart
#

the main thing we need to decide on is what the 3 numbers should stand for and how the alpha/beta markers should be used

#

for that I had this proposal

boreal blade
#

then in that case, we should just have major.minor.bugfix, where:

  • major = breaking changes in neo (caused by minecraft or neo itself)
  • minor = new features or minecraft versions (e.g. mc1.2.3 vs mc1.2.4 or neo adding a new convenience api)
  • bugfix = a number incremented for every bugfix
    and for prereleases:
  • snapshot.snapver for snapshots (e.g. snapshot.23w35a)
  • rc.rcnumber for release candidates (e.g. when a new Minecraft version drops and we think we're almost stable)
  • beta.betanumber for nightly builds (builds when main is committed to)
  • alpha for dev builds (in IDEs and the like, or maybe for PRs)
    and for build metadata:
  • mc.mcver for minecraft versions (e.g. mc.1_7_10 or mc.1_20_1)
  • sha.hash for build commits (e.g. sha.0974ecc)
  • dirty for dirty builds (in IDEs and the like)
ashen heart
#

careful snapshot, rc, beta, alpha would compare lexically

#

also snapshot is not a good idea because maven handles that different

rapid totem
#

Maven specifically handles the -SNAPSHOT version suffix, iirc

boreal blade
#

the thinking here is that:

  • snapshots aren't stable so they're an important part of the version
  • we'd likely want builds going out for full testing
  • we'd also want to build main to make sure it succeeds and allow testing against these in-flight versions
  • we'd want to distinguish dev builds, these should never get published to maven
  • we want the mc version in the build metadata so it's in the filename
  • we want the sha in the build metadata so that if a user reports a bug we have an exact commit to start searching from
  • we want the dirty status in the build metadata so we can tell if the build was clean
#

the goal is that this metadata can be combined to some extent, so for example, 1.0.0-snapshot.23w35a.alpha+mc.1_20_3.sha.0974ecc.dirty would be a full version number

ashen heart
#

I think maintainer controlled versioning was something that is not wanted

#

so it should all be done automatically

boreal blade
#

I personally really dislike that idea because it makes it a lot easier for breaking changes to sneak in to supposedly stable versions

rapid totem
#

I want maintainer-controlled versioning
I don't know the opinions of the others on the team, except perhaps Curle

boreal blade
#

I would gladly support writing tools and automations to make the release management a lot easier

supple panther
silent ginkgo
#

Go use Minecraft enchantment table language

thorn prawn
#

In my mods, I use manual versioning. However, I think auto versioning makes a lot of sense for neoforge. Every change gets a build. It also means you can easily identify what commit broke something. But being able to disable builds for things that don't change the final output would be beneficial. Especially when GitHub has features now to merge queue multiple things at once, I don't think it's much of a concern to use auto versioning

supple panther
#

thats just the standard galactic alphabet with magical sounding words

boreal blade
thorn prawn
#

But it's not beta

boreal blade
#

(and when to make that release)

thorn prawn
#

it's feature complete

#

ready for production

boreal blade
#

it's "beta" in that it hasn't been fully tested

thorn prawn
#

It should be

ashen heart
#

that's why my proposal exists

thorn prawn
#

anything that makes it to the main branch after breaking change period should not be reverted unless extreme circumstances

ashen heart
boreal blade
#

doing a full test on every PR isn't really feasible, especially considering that some PRs may interact with each other

thorn prawn
#

As I see it, if we use manual versioning, the # of commits will just double... As we will just be spending half the time bumping a number cuz we want things to build a version

thorn prawn
#

having to test inter-PR functionality is understandable but it should still be fully tested

#

the merger takes on any responsibility of issues

boreal blade
#

by "full test" I mean something like forgecraft 😛

#

the idea would be that something like forgecraft would use the -beta builds to test and develop against

thorn prawn
#

So we are relying on forgecraft now to test our product?

#

lol

boreal blade
#

no, I was using it as an example of what I meant

thorn prawn
#

I would prefer we get it right the first time

boreal blade
#

that's never going to happen, you should know this by now 😛

#

the whole point behind my proposal is that we're accepting that we won't always get it right and designing in checks to allow us to spot and fix these problems before it goes out to users

thorn prawn
#

Why not just use the actual snapshot name for the snapshot field? And what about April fools

#

And what about pre releases and RCs

boreal blade
#

and there needs to be proper tooling to make the release management a lot easier so there's not "bump version" commits

thorn prawn
#

And how does it sort

ashen heart
thorn prawn
thorn prawn
#

you are suggesting keeping an int count of the snapshot # we are on

ashen heart
thorn prawn
#

but idk why vs just using the actual snapshot name

ashen heart
thorn prawn
#

ah fair enough

#

I think the problem is wouldn't any version suffixed with -beta and -alpha be sorted after the original version?

#

I guess you would have to bump the patch version after a -beta or -alpha cycle

ashen heart
thorn prawn
#

There's no winning because either beta and alpha get sorted before the base version and then you're fucking over version ranges or it's sorted after the base version then you have to delete the suffix and bump the number

#

maven I believe

boreal blade
#

If we tell people to use semver, a la 1.2.* then yes, prerelease versions are not included. I'm not 100% sure how gradle would deal with it, but we could likely add tooling to use semver versioning for downloading neoforge through neogradle

analog badge
#

Are we talking BC period or snapshots now?

thorn prawn
analog badge
#

Snapshots could be alpha or pre releases, but I'd rather keep clean numbers for normal mc version releases

thorn prawn
#

elaborate

boreal blade
#

if I understand correctly, the version that somebody downloads just to play with mods should look like 1.2.3+mc.4_5_6

ashen heart
#

more like neoforge-1.0.0+1.20.3.jar

boreal blade
#

yeah, something like that

analog badge
#

What if:

Non-snapshot builds

Use x.y.z as the version:

  • x is a number indicating the Minecraft version
  • y is 1 in the breaking change period and always 2 after
  • z is the commit count for the x.y series
  • the concept of recommended builds disappears, and instead we only have latest

Snapshot builds

Same as before but y is set to 0.

#

Alternatively, x.{0,1}.z for non-snapshot and x.0.0-pre.<snapshot name>.<some commit count>

#

Most importantly we keep the automatic versioning

#

And we keep things dead simple...

remote apex
tropic wave
#

so, the first snapshot build for 1.20.2's prereleases would be 1.20.2.0.1

analog badge
#

I was thinking 48.0.0

boreal blade
#

I honestly really dislike the whole concept of the "breaking change period", because it discourages making major changes until the next minecraft version where the changes you're making don't even make sense

wooden sage
#

I've said it before and I'll say it again: my biggest gripe with the current system is that middle digit and if we're changing anything we should change that. The "0 is BC window, 1 is RB" setup makes no sense, honestly

analog badge
#

Monica that's not gonna change. We must keep the versions stable past some point

tropic wave
#

I dunno, it makes sense to me 🤷‍♀️

thorn prawn
boreal blade
wooden sage
#

It should be obvious at a glance that a BC window build is not stable and that a post BC window build is stable till the next BC window

tropic wave
#

yes, and the middle digit is what we use to indicate that it's a BC window build

wooden sage
#

Just look at what happened when the license field got added - was that back in 1.12?

tropic wave
#

no, after that

boreal blade
tropic wave
#

1.14 or .15 or .16 was the license field

tropic wave
wooden sage
boreal blade
#

that's already the case though ¯_(ツ)_/¯

wooden sage
wooden sage
remote apex
#

but it's not? as it stands with forge throw any 1.20.1 mod in and it will probably work...

wooden sage
#

Post BC window basically everything will run on latest

ashen heart
#

I really really dislike the ambiguity in having the middle number be a boolean for snapshot that is what pre release markers like alpha/beta are for

wooden sage
#

That's exactly what I'm saying

#

Is the only worry with using prerelease versioning for BC window stuff that it'll be included in the wrong range for maven versions?

#

If that's the case why don't we change the mods.toml spec to use something more sensible than maven version ranges that allows blurrier edges?

#

The system fabric uses is pretty clever for this sort of stuff though there's any number of potential solutions

ashen heart
#

i think fabric uses semver

#

or a modified version of it

wooden sage
#

They use a sort of semver version range, yes

ashen heart
#

my idea is convert the maven version range to a semver range and use that to match

wooden sage
#

That wouldn't work

ashen heart
#

why not?

wooden sage
#

The semver version range >=3.0.0 <4.0.0 still contains 4.0.0-alpha

#

You need to use the different types of semver version ranges

woeful sphinxBOT
#

An exception was thrown: Invalid version: >=3.0.0 <4.0.0

wooden sage
#

What I would instead allow is the use of 4.0.0- in maven version ranges

woeful sphinxBOT
#

Semver versioning: 4.0.0-alpha ∈ >=3.0.0 <4.0.0

wooden sage
#

Where that versioning is a special prerelease that can't exist, and is before all other pre releases

lethal scarab
#

Note that the bot's semver parsing has a lot of known bugs atm...

wooden sage
#

The other option is the, like, ~ prefix on semver version ranges or whatever else it allows

woeful sphinxBOT
#

An exception was thrown: Invalid range: >=3.0.0 <4.0.0-

#

Semver versioning: 4.0.0-alpha ∉ ^3.0.0

wooden sage
#

There you go, there's a solution

ashen heart
wooden sage
#

Because with semver, prereleases are still before actual releases

ashen heart
wooden sage
#

From semver.org:

When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version

ashen heart
wooden sage
lethal scarab
#

It's almost as if semver is hard to fully implement correctly and has varying opinions and bugs...

wooden sage
#

That range means >=3.0.0 and <4.0.0. Prereleases obey that, according to the semver rules of precedence. It's that simple

remote apex
wooden sage
#

There exists other tools, like the ^ and ~ prefixes, for comparisons that have fuzzy upper bounds

lethal scarab
remote apex
#

yeah those aren't bugs you tried with invalid versions

tropic wave
#

the problem is that if I want my mod to depend on norge [3.0.0, 4.0.0), then I don't want it to be used with prereleases for 4.0.0, so we cannot use semver semantics

lethal scarab
#

Apparently 1 - 3 not containing 2.1 is not a bug now

remote apex
#

1.0 is an invalid semver version

lethal scarab
#

And 1.0.* not containing 1.1.1 is not a bug either

wooden sage
lethal scarab
#

Or that ^1.0.0 not allowing 1.0.1 is correct

#

Gimmie a break maty

woeful sphinxBOT
#

An exception was thrown: Invalid range: >=^3.0.0

remote apex
#

again you tested with 1.1 which is an invalid version

woeful sphinxBOT
#

Semver versioning: 4.0.0-alpha ∉ ^3.0.0

tropic wave
#

why are we even using semver

woeful sphinxBOT
#

Semver versioning: 3.0.0 ∈ ^3.0.0

#

An exception was thrown: Invalid version: 2.1

lethal scarab
remote apex
#

yes that's correct?

#

^ is >= && < nextMajor

wooden sage
wooden sage
#

The bot is correct though

#

It's >= on the low end, yes

lethal scarab
remote apex
wooden sage
#

But yeah, allowing caret ranges solves the issue with using prereleases quite handily in my mind

lethal scarab
#

You're telling me 3.0.0 is not included in >=3.0.0 now maty...

remote apex
#

wut are you on about mate

image.png
wooden sage
#

If someone wants a weirder range, they can use multiple ranges: >4.2.3 <=5.0.0, ^5.0.0 gives you stuff from 4.2.3 till 5.0.0 prereleases

lethal scarab
#

My bad, I didn't see the cross through the symbol

#

I'm used to == and =/= kind of format

woeful sphinxBOT
#

An exception was thrown: Invalid range: >4.2.3 <=5.0.0, ^5.0.0

wooden sage
#

Does the bot support multiple ranges?

#

I'm guessing not from that

#

But that's a simple "or" so not the hardest part to implement

remote apex
#

not comma separated

#

or is ||

wooden sage
#

Ah, makes sense

remote apex
#

https://www.npmjs.com/package/semver the grammar and spec

npm
semver

The semantic version parser used by npm.. Latest version: 7.5.4, last published: 2 months ago. Start using semver in your project by running npm i semver. There are 26729 other projects in the npm registry using semver.

woeful sphinxBOT
#

Semver versioning: 5.0.0-pre.1 ∈ >4.2.3 <=5.0.0 || ^5.0.0

wooden sage
#

Uh, wait, wrong range

woeful sphinxBOT
#

Semver versioning: 6.0.0-pre.1 ∉ >4.2.3 <=5.0.0 || ^6.0.0

wooden sage
#

Wait wrong again... Gah

woeful sphinxBOT
#

An exception was thrown: Invalid range: >4.2.3 <=5.0.0, ^5.0.0

#

Semver versioning: 6.0.0-pre.1 ∉ >4.2.3 <=5.0.0 || ^5.0.0

remote apex
#

I see you're having a great time with your clipboard

wooden sage
#

That's the comparison

#

Basically, that range means "4.2.3 till 6.0.0, but no 6.0.0 or prereleases of 6.0.0"

#

And is pretty easy to express, especially if you're not on mobile and keep hitting the wrong keys

remote apex
#

I mean can't you also >4.2.3 <6.0.0

wooden sage
#

No. That includes 6.0.0-beta

remote apex
#

hmm right

wooden sage
#

That's the same issue as maven version ranges. Semver version ranges solves it

woeful sphinxBOT
#

Semver versioning: 6.0.0-pre.1 ∈ >4.2.3 <6.0.0

wooden sage
#

But that's why you can't just change the semantics of maven version ranges and call it a day

#

You need to support caret ranges. Which are a proper solution for this

remote apex
#

well

woeful sphinxBOT
#

Maven versioning: 2.0.0 ∈ [2,3.0.0-a)

wooden sage
#

I'd also say go with flexver, not semver, which can have any number of components

woeful sphinxBOT
#

Maven versioning: 3.0.0-beta ∈ [2,3.0.0-a)

remote apex
#

hmm

#

thanks maven

wooden sage
#

I believe alpha and beta have special cases

remote apex
#

yeah

#

hmm tho

stoic sedge
#

Solution, do a community wide poll on neoforge versioning!

woeful sphinxBOT
#

Maven versioning: 3.0.0-beta ∉ [2,3.0.0-alpha)

stoic sedge
#

What can go wrong

woeful sphinxBOT
#

Maven versioning: 3.0.0-alpha ∉ [2,3.0.0-alpha)

remote apex
#

I mean that works

wooden sage
#

I'd say caret ranges are more elegant, but yeah, it's technically possible

woeful sphinxBOT
#

Maven versioning: 3.0.0-alpha.1 ∉ [2,3.0.0-alpha)

remote apex
#

tho

woeful sphinxBOT
#

Maven versioning: 3.1 ∈ [1,2)[3,4)

#

Maven versioning: 3.0.0-a ∉ [2,3.0.0-alpha)

wooden sage
#

...which means imo there's no excuse not to use pre releases for BC window stuff

remote apex
#

that should be smaller thinkies

wooden sage
#

No it shouldn't be

#

Alpha and beta come before everything

#

Blame maven

remote apex
#

lovely

#

the biggest problem with flexver and semver is that their spec only defines how to compare versions

#

not ranges

wooden sage
#

When would you even compare ranges? Like, intersections/unions of ranges?

#

Turns out you only need to know how to compare individual versions for that one

remote apex
#

no i mean the range spec

wooden sage
# remote apex no i mean the range spec

Oh sure. Yeah, but go with a spec of a standard implementation (the one on npm for instance) or one used in the modding world (fabric/quilt's solution) and you're good to go

remote apex
#

hmmm how semver compliant is fabric. does it require exactly 3 components

wooden sage
#

I think they allow more/less than 3

#

Which we'd want to too

#

Because this needs to consume mod versions

#

And not all of those have exactly 3 components

#

... honestly, I'd be happy if neoforge did: x.y

  • x is the major version, updated once per MC version.
  • y is the number of commits since the end of the BC window
  • add -pre.z for BC window or -alpha.w for snapshots
    Could add a third digit if you wanted to too, of course, or add a +mc_version to clear stuff up too
#

And then use either what Maty showed with maven version ranges or caret ranges to exclude the prereleases from the range in a mods.toml

remote apex
#

I'd say BC is more like beta but yeah

wooden sage
#

Oh sure

#

Either way

remote apex
#

for carets we do pmuch have to switch to flex/semver

wooden sage
#

Yes. I'd say that's a decision to be made - whether to stick with maven ranges or not. This is only about the ranges, though, and has no impact on the actual version scheme we pick

wooden sage
boreal blade
wooden sage
#

Oh sure semver version ranges support something like that too I think

#

Hmm, what was it...

woeful sphinxBOT
#

Semver versioning: 6.0.0-alpha ∉ 5.x

wooden sage
#

That's it

remote apex
#

or *

wooden sage
woeful sphinxBOT
#

Semver versioning: 1.19.3 ∈ 1.19.*

boreal blade
#

yeah

remote apex
#

biggest problem with semver is that the spec wants exactly 3 components

wooden sage
#

That's easy to change though

#

Fabric and quilt both did

remote apex
#

yes but that's not semver

wooden sage
#

I mean. Strict adherence to specs will only cause us pain in a world where we're modding a game

boreal blade
#

there's also NuGet versions which can support four components as well as the rest of semver

wooden sage
#

Might as well use flexver at that point though, which has arbitrary components

boreal blade
#

(the nuget grammar is identical to semver versions except it accepts an optional leading digit for compatibility with older .NET stuff which used the four digits, most stuff uses three digits now)

remote apex
#

we should create neover

wooden sage
#

Honestly? If we don't just stick with maven ranges, whatever solution we use to parse versions and version ranges should be bundled as a separate library and distributed on maven central, and should have a written out spec, yes

#

But if we do stick with maven ranges that "alpha comes first" thing actually saves us and means we can still use prereleases for BC window just fine

remote apex
boreal blade
#

Yeah, that's kinda why I was proposing nuget's solution since it's already fairly well-established and understood by people

#

And also has the extra digit so we could do 19.4.x.y for versions if people really want that

wooden sage
#

Yes but "exactly 4 versions" isn't good when people definitely use, like, 2 or 5 or stuff. We can't break existing versioning schemes of mods. Any version that is currently a valid mod version, should keep being one. And as currently that's any maven version, we need to support that

#

We can't constrain versions in a way they're not already constrained

boreal blade
#

considering that we're making breaking changes for the next MC version, moving to a different versioning scheme seems like it would be fine, especially if it means in general version checking is more consistent ¯_(ツ)_/¯

wooden sage
boreal blade
#

.NET did just that and everyone managed fine 😛

wooden sage
#

Neoforge isn't .NET. Frankly, I see no reason to limit versions to "exactly 3 or 4 components" if we're not forcing strict semver, which would be a bad idea anyways.

#

If we're already allowing 4 components, might as well just make it arbitrary so it works with all versions that currently do

analog badge
#

Let's keep maven versioning since it's been used for some time and works fine

#

The intent of semver is to get a message across regarding the kind of changes just by looking at the version. In the context of Neo, this message is worthless because we ask users to always use the latest Neo version for a given Minecraft version

#

Yes everyone is used to semver, however you have to understand that it solves a problem that is not relevant to Neo at all

#

Now, I think 0/1/2 minor version for status is fair enough since it has the most important property of being increasing. The question is how we choose the major version

#

We could probably do 1902, 2001, 2002, etc

#

I think we should keep maven versioning, so 1.20.2.0.1 is not usable

#

But 2002.0.1 would work

#

I think 48.0.1 is also fine, maybe as 48.0.1+1.20.2 if we want the mc version in the artifact

wooden sage
#

We can keep maven versioning and still use a prerelease for BC window...

#

And frankly I see no reason not to do so given that a prerelease is kinda the intended method, in both maven versioning and semver, of communicating exactly this thing

#

See: #1137179119713529876 message

#

The version range issue isn't really an issue as maven puts alpha as a special "first" prerelease

analog badge
#

Pre releases are extremely awkward to use. We moved away from them in AE2 for that reason

wooden sage
#

Why are they awkward to use?

#

They, semantically, get across the information in question far clearer than using the middle digit for that does

wooden sage
analog badge
#

Does it? I thought it was 3 numbers and a patch

analog badge
#

Semver is not useful for our users

ashen heart
#

to fix those issues this seems to be a good proposal (since it starts the patch version at 1 to prevent non stable from matching)

#

we just need to strip meta manually before matching to ignore it

#

but I still think we should use alpha and beta flags instead of a number meaning the same thing since it is easier to understand for the people that have not read the version spec

tacit cloak
#

So what's the current TL;DR about versioning? I was busy this afternoon

#

also, I don't expect anyone to use it, but I did write this this afternoon. (No that's not why I was busy lol)
https://github.com/gigaherz/Versible
Supports intervals, comparison operators, and wildcards.
It's designed for consistency instead of intuitiveness, so: 2.0-alpha < 2.0 < 2.0.0-alpha < 2.0.0 (yeah 2.0 != 2.0.0 in this library, I expect people will hate that with a passion but it fixes the consistency)
TODO: make the parsing tests more thorough, especially invalid inputs, and I have to finish writing javadocs

image.png
wooden sage
#

I'd say people can just specify the maven range [1.2.3, 2-alpha) to miss out on any of the snapshots, because maven treats alpha special and shoves it first

#

Or use semver ranges instead with caret ranges or wildcards

wooden sage
tacit cloak
#

no that's the whole point, it makes the whole thing more consistent, at the cost of intuitiveness

wooden sage
#

It's just unintuitive

#

And limited

tacit cloak
#

I disagree, having 2.0-alpha included in [1.0,2.0) is not consistent with the numbering

wooden sage
#

It's unintuitive, yes

#

But at some point you're arguing semantics

tacit cloak
#

we disagree on semantics, then

wooden sage
#

But regardless I don't see the benefit your system would bring over semver ranges

#

Which allows the same thing with less... Funkiness

tacit cloak
#

anyhow I know people will hate that. I knew it before I started coding. but I wrote it regardless because IMO, it's the better solution.
so I offer this solution to the world. will the world take it? probably not. that's fine. I just want it to exist.

#

but really, despite 2.0 != 2.0.0, the ranges work intuitively in almost every possible case, and perfectly match the definition of the intervals

#

every unique value of a version has a place in the line

#

tomorrow I'll write the readme and javadocs, so that people can understand my rationale and all the details about what the design implies

wooden sage
#

That's fair. Personally, I'd say that either sticking with maven ranges or using semver/flexver ranges would work fine - after all, this issue isn't really an issue with either of those two (due to the solution for maven ranges of just bounding based on the first possible prerelease). I'd definitely say that neo's versioning should use prereleases though

analog badge
#

We're not gonna use custom version parsing / comparison code

analog badge
#

I'm a bit worried that an impractical versioning scheme will be chosen just because "semver good, everything else bad"

boreal blade
#

Yeah, frankly I feel at this point we should just do x.y.z+mcver style versioning where we bump major on breaking changes and minor.patch can be whatever (new features, build number, whatever)

#

i definitely very much want the first number to change whenever there's a breaking change that is important for me to look at

#

(like if the capability or registry stuff goes in separately, i want to make sure i don't have a mod that claims to be compatible but is in fact completely broken)

tropic wave
#

I forget, why can't we just do 48.0.1

tacit cloak
#

yeah, I will repeat what I think should be the minimum requirements for versioning:

  1. breaking changes = major version bump
  2. in-dev / stable should be differentiated somehow (I don't care how)
  3. monotonic
ashen heart
#

the things I want from the versioning scheme:

  • mc version in non significant part (so it shows up in artifact file name)
  • NO version information in the artifact name
  • it needs support the possibility of froge releases (releases for snapshots)
  • it needs to support a BC period that is clearly visible in the version (no prior information needed)
tacit cloak
#

forge's versioning scheme fits all 3, except in-dev is flagged with .0 which is not easy to figure out by users that don't already known

ashen heart
tacit cloak
#

that doesn't really matter IF we change the modid to neoforge

tropic wave
boreal blade
#

yeah, breaking.x.y[-alpha/beta/rc/whatever]+mcver

tacit cloak
#

which IMO should be a hard requirement

boreal blade
#

honestly i want the versioning to restart at 1 too, because it lets us make things clearer

tacit cloak
#

I don't think neo should release for 1.20.2 with the intention to break forge compat, and still use "forge" anywhere in its metadata

boreal blade
#

though since forge/neo use the same loader (mostly) i can see wanting to keep the loader version the same

ashen heart
boreal blade
#

assuming the loader is still compatible, it should use the same versioning as forge; if it's also breaking then it should start at 1

tacit cloak
#

so, if we go for forge versioning and continue from 48 (with neoforge modid), I'm good.

#

if we pick 48.0-alpha.1 I'm also good

stoic sedge
#

do a community poll for versioning~ Totally will work out just fine! (joking)

tacit cloak
#

if we restart with either format, I'm good

boreal blade
#

yeah, my wishlist is:

  • major version = indicator of breaking changes
  • minor/patch version = whatever, could include the build number
  • prerelease identifier = alpha/beta/dev/whatever
  • metadata = minecraft version
#

i'd probably do minor = recommended builds, where 0 = "we're still soliciting changes for this version" and >1 = "we've pretty much settled on the final api for this version"

#

the minor may necessitate bumping if there are minor additions (like for example a new api which makes certain use cases easier, but is technically possible without it)

analog badge
remote apex
#

why? we are a new project

#

we don't have 47 prior releases

#

we don't need neo 48.0.3 and forge 48.0.3 to coexist with entirely different apis

boreal blade
#

yeah, restarting versioning from 1 makes it very clear that it's a different project with different goals to me

#

and is very much not compatible

tropic wave
#

wouldn't that cause problems when we get back up to 47 again

#

or do we just pull a Windows 10 and skip it

boreal blade
#

i mean, yesn't

analog badge
#

There's no good reason to not continue with the versioning, IMO

#

What if we ever decide to continue an old version? (Unlikely but still)

boreal blade
#

yeah, backporting is probably the one major reason why we should continue with the current version numbering

#

personally i don't see much point in that endeavour but i'm not everyone

tacit cloak
#

we shouldn't be using net.neoforge.forge either way, but specially not if we restart

analog badge
#

"we should" without any argument to back it up 🤔

wooden sage
#

Honestly, I think that x.y[-alpha.a][-beta.b]+mc is not a bad solution

#

x bumps on MC versions, y bumps per commit

ashen heart
#

maybe we could do 1.0-beta.1 as the first version

wooden sage
#

a and b are for snapshots and BC region stuff

wooden sage
boreal blade
#

there's also the possibility of moving older versions to an "archive" maven so they're still accessible, but wouldn't "conflict" with regular versions

ashen heart
wooden sage
#

Or rather, 1.0-beta.1+1.20.2

#

We don't need three digits if we only use two

tacit cloak
ashen heart
#

so basically my proposal but with 2 instead of 3 components

remote apex
#

and that too

#

we're not forge and we don't have the same api as forge

#

it's like ae2 calling itself refinedstorage

analog badge
#

The way I see it it's more like ae2 calling itself "ae"

#

Changing the modid makes sense

#

We should change the modid

#

But we don't need to restart the versioning

boreal blade
#

actually if we backport neoforge it's probably gonna have to use the forge modid/artifact for compatibility anyway so it's not like it'd be an issue 🤔

tacit cloak
#

remember, people can do this to be compatible with both loaders, only if we change modid ```toml
[[dependencies.mod1]]
modId="forge"
mandatory=false
versionRange="[48.0.17,49)"
[[dependencies.mod1]]
modId="neoforge"
mandatory=false
versionRange="[48.0.5,49-alpha)"

wooden sage
#

Is there a reason not to restart versioning if we're already changing the mod ID?

#

Like, it's a new thing

tacit cloak
#

continuity

wooden sage
#

So it should have new versioning

tacit cloak
#

suppose we choose to support 1.19.2

boreal blade
#

continuity with what though? 😛

tacit cloak
#

what version do we call it?

remote apex
wooden sage
#

Ah, that's not a bad point

remote apex
#

it's also not necessarily one we need to think of

wooden sage
#

Okay, so the first release for 1.20.2, under my proposal, would be 48.0-beta.1+1.20.2 then

#

Though honestly I still think restarting versioning is easiest

remote apex
#

old versions have been mostly dropped and by the time we decide on deving on an older version IF we do people have moved one

wooden sage
#

If we're backporting stuff, that'll probably be a special release cycle anyways

mossy flume
#

There's a good thing to argue that the 48 represents the version of Minecraft that it's built for (1.20.2 being roughly the 48th release)

#

So we could just, like

#

Move that into an actual part of the version

wooden sage
#

That would be easier if minecraft stuck to a somewhat normal versioning

boreal blade
#

Yeah, I feel that if we're backporting we'd probably have to use the forge modid, or something like neoforge-legacy-119

tacit cloak
#

someone suggested 1.20.2.x for neo builds but I find that horrible to look at :P

remote apex
#

that number is probably off by like 10 at this point

wooden sage
#

But what about 20.2.0-beta.1?

remote apex
#

let's see how off it is actually

wooden sage
#

Then, say, for MC 1.30 you'd have 30.0.0

tacit cloak
#

the issue is .2 feels weird since it's still a major break XD

wooden sage
#

Yeah, I agree

#

But hey, we don't need to follow strict semver

#

Just, like, "makes enough sense" versioning

ashen heart
#

Proposal

  • artifact-name/modid: neoforge
  • version: x.y+mc
    • x = breaking change from mc/neo
    • y = build number after release
    • -beta.b added in breaking change period
      • b = the build number inside the breaking change period
    • -alpha.a added for snapshot versions
      • a = the build number inside snapshot versions
    • mc = minecraft version
tacit cloak
#

so I still prefer either full restart and bump on breaking changes window opening
or we continue with forge's versioning

#

the rest I feel is nitpicking and whatever I don't care enough

wooden sage
tacit cloak
#

1.0-alpha.1
1.0.0-alpha.1
1.0.1

#

all are good to me

boreal blade
#

On the backporting stuff, what if somebody made a single jar mod compatible with 1.18, 1.19 and 1.20? how would they specify the completely incompatible "forks" of neoforge that would exist for each version? I feel that would have to be a separate modid

tacit cloak
#

also since we are not doing snapshots, and if we ever do them odds are it's better to use a different artifact id,
IMO we should use -alpha for in-dev porting, such as the case for 1.20.2 neo which will release with missing major breaks

ashen heart
tacit cloak
#

no point reserving -alpha for snapshots

wooden sage
#

Sure. As long as we also have -beta for BC window

tacit cloak
#

yes, -alpha for "we are still porting stuff", and -beta for "all the breaking changes that were approved by the community, have been merged"

wooden sage
#

No reason you couldn't use -alpha for snapshot and in-dev. Like, especially if you add the +MC-version to the end

remote apex
#

lol

sleek tinsel
#

Personally i dont really like +mc, but i have no solution other than mc-

mossy flume
remote apex
mossy flume
#

Keep in mind some versions were stable for many years

tacit cloak
#

so TL;DR from me: do whatever you want, but change the modid please :P

remote apex
#

yeah so we don't need to break the stability and introduce neo for 1.12

mossy flume
#

The interval between updates prior to 1.7 averaged to like, 2 years

#

That's Forge updates, not Minecraft

boreal blade
#

basically balancing what's convenient for modders vs what's convenient for users

#

(modders specify their minecraft versions in a different way)

sleek tinsel
#

Currently, don't we only have the mc version in artifact names? how does +mc benifit us over mc- the way its been for years (speaking of making sense to users)

tacit cloak
#

IMO the mods.toml version for neo should exclude the +mc part

#

it should only be in the maven release for metadata purposes

sleek tinsel
#

iirc it always has excluded the mc version

tacit cloak
#

in semver, "1.0.0+abc" is a tag

#

it isn't uses for comparison

boreal blade
#

yeah, anything after the + is ignored

tacit cloak
#

I think someone said maven does NOT ignore it?

remote apex
boreal blade
#

til

#

i'm stuck in semver land where it doesn't 😅

remote apex
#

as I said many times

#

maven bad

boreal blade
#

makes sense

woeful sphinxBOT
#

Maven versioning: 1.0+a < 1.0+b

tacit cloak
#

but still

woeful sphinxBOT
#

Maven versioning: 1.2+abc ∈ [1.2,1.3)

tacit cloak
#

so it works for basically all use cases

woeful sphinxBOT
#

Maven versioning: 1.2+abc ∈ [1.2,1.3-alpha)

boreal blade
#

yeah it's basically about getting rid of having to specify the minecraft version everywhere, since i assume requesting neoforge 1.2.3 will accept 1.2.3+1.20.2

tacit cloak
#

I have no idea if maven (gradle maven support) allows specifying a version without the +tag

woeful sphinxBOT
#

Maven versioning: 1.0+a ∉ [1.0+b,)

remote apex
#

thanks maven

sleek tinsel
#

But you already dont have to specify the mc version everywhere with mc- as its only in the maven artifact names, moving it to +mc, and still excluding it from the in-game version number does nothing different than the current system

boreal blade
wooden sage
sleek tinsel
#

and?

tacit cloak
#

I mean we could exclude mc in the interna lversion

wooden sage
#

In gradle too

sleek tinsel
tacit cloak
#

modstomlversion = NEO_VERSION
mavenversion = MC_VERSION + "-" + NEO_VERSION
would work fine really (I mean it's literally how forge does it and has been doing it for ages)

wooden sage
sleek tinsel
wooden sage
#

Why is the MC version required in gradle? Why can't we just move it to metadata, so that the gradle version and mods.toml version line up?

#

Like, for forge in gradle I have to specify 1.20.1-47.1.75 or whatever. Wouldn't it be better to just have 47.1.75+1.20.1 everywhere and have the same versioning scheme everywhere?

sleek tinsel
#

How does that change anything though, Your still specifying the Minecraft version.

wooden sage
#

Yes but the version in the mods.toml is the same as the version in the gradle file

remote apex
#

well technically

#

you can then do [47,) as a range for the dep

wooden sage
#

I don't have to separately track a "forge version" and a "MC version". I only track a single, unified forge version

wooden sage
remote apex
#

and always use the latest neo version harold

wooden sage
#

But basically, you currently have to specify, separately, two things that are really the same thing

#

So if we could unify that, is there really a reason not to?

#

Like, I'll turn that back around on you: why does using 1.20.2-whatever change anything as compared to using whatever+1.20.2?

sleek tinsel
#

Do you have any documentation references that you can site for +blah being a tag, ComparableVersion and DefaultArtifactVersion, the stuff we use for parsing dependencies does not support excluding +asdf from the comparison

mossy flume
#

I think covers point is that it literally doesn't change anything - it's what we use now

sleek tinsel
#

^

#

Its just moving it for the sake of moving it

#

it does literally nothing

#

If anything, it would confuse end users, as Forge, the thing they have known how to download for years, now suddenly has different versions. The masses are not smart.

ashen heart
#

but that doesn't work for mods the idea was to be an example for mods but for mods that special casing with the mc version on the fron does not exist

sleek tinsel
#

? what special casing?

#

Forge does not special case anything with versions, it literally just does not prepend the mc version in its mods.toml

wooden sage
#

I'm saying whatever we do those two should be the same

#

And the easiest way to do that without weird side effects is to move it to metadata

ashen heart
#

version in build.gradle = 1.19.2-43.2.0
version in mods.toml = 43.2.0

wooden sage
#

If you use metadata, you can do version range comparisons without the metadata

#

So it's not necessary in the mods.toml

ashen heart
#

but for mods it would be:
build.gradle = 1.19.2-1.0
mods.toml = 1.19.2-1.0

tropic wave
#

from my worldview, in my build.gradle I depend on forge 1.20.1-47.1.3, in my mods.toml I depend on minecraft 1.20.1 and forge 47.1.3

so... they are the same number

wooden sage
#

But if you add it it's still all valid

sleek tinsel
#

Nothing i have seen with maven versioning, mentions anything to do with metadata, i have asked for citations, and have received nothing

#

please cite

# 
loaderVersion="[${lang_version},)"
[[dependencies.mod1]]
    modId="forge"
    mandatory=true
    versionRange="[${forge_version},)"
    ordering="NONE"
    side="BOTH"
[[dependencies.mod1]]
    modId="minecraft"
    mandatory=true
    versionRange="[${mc_version}]"
    ordering="NONE"
    side="BOTH"

processResources {
    filesMatching('META-INF/mods.toml') {
        expand 'mc_version': forgeVersion.split('-')[0],
                'forge_version': forgeVersion.split('-')[1],
                'lang_version': forgeVersion.split('-')[1].split('\\.')[0]
    }
}
#

magic

remote apex
wooden sage
sleek tinsel
#

If maven does not support it, i think the entire argument of using it is moot

wooden sage
#

They just treat it slightly differently

#

In a way that still works for us

remote apex
#

it's treated as a qualifier

#

i.e. part of the version

sleek tinsel
#

^

wooden sage
#

But not as a prerelease

#

Which is important

#

And makes it useful

#

Because qualifiers will still work fine with version ranges

#

See #bot-commands message for another good example

#

Unlike the current system, this would let you have a single, unified version which:

  • can be compared against version ranges specified with or without the MC version
  • contains the MC version
  • still allows for -beta and -alpha stuff
  • doesn't leave you with two different neoforge versions in two different places
#

There is no reason that the neoforge artifact should have a different version than the neoforge mod

sleek tinsel
#

Why does NeoForge need to declare the mc version as part of its dependency, when we have the minecraft mod. If this were to be used for that, and we could do partial versions PLUS the mc version depdency purely with the neoforge version, i'd see the benifit. I see absolutely no benifit to this over the current system, besides the few people who do not build-time replace their mods.tomls

#

Your entire argument is hinged around having to declare it in 2 different places, the solution to that is: instead of still declaring it in 2 places, declare it in one and auto-gen the other. This is simple gradle stuff. That snippet i pasted above works, dev time and release time.

wooden sage
#

My argument is not about having to declare in in two different places. It's about having two different versions. Any comparisons and checks I do in terms of versions at compile time are inherently wrong to do at runtime with the current system

#

Additionally, why should I specify both a MC and a forge dependency in my mods.toml when the forge version determines the MC version present?

#

Seems redundant to me...

#

Especially because I only ever depend on a MC version in dev by depending on a forge version

#

So what I'm actually depending on, at runtime, is "this forge version and the MC version it comes with"

sleek tinsel
#

because you generally declare a [34.23,) dependency on Forge, which, if you dont declare a [1.19.2] dependency on Minecraft, means Forge will attempt to load your mod on newer incompatible versions

#

using tags does not solve that

wooden sage
#

Especially as most people don't use a [1.19.2] format dependency

#

They use [1.20,1.21) or [1.19.2,1.19.3)

mossy flume
#

Well, that'd be invalid anyway

wooden sage
#

Cause that's what the MDK does

wooden sage
mossy flume
#

It needs a range, which means [1.19.2,]

#

A single version is an invalid range

wooden sage
#

Which leaves the endpoint open just like covers was trying to avoid