Possibly change old tags and/or at least use semantic versioning going forward about openage

[TheJJ]

The major version equals the current milestone. The first usable release will probably be v15.0 then. I thought about using v0.$milestone, but once we reach v1.0, what next? This is why i chose this version model for now, each milestone will be a major version even after the current milestone list is finished.

For a game, i think the semantic versioning is less suited as it is for production software, libraries etc.

[boombatower]

Seems like hard wiring milestones to version tags is a mistake. Down the road I would expect bug releases and such which will muck up milestone releases and even overlapping milestones and such where you want to release new stuff, but a particular milestone is not complete. Milestones are goals for development (or even versions), but they shouldn't be thought of as the versions themselves.

Half the point of this seems to be enhanced modding/scripting/etc and even people making other games off the engine which means the API and which version mods are compatible with would definitely benefit from semver.

[TheJJ]

It makes sense for projects that are commited to a stable API or similar, not for us in my opinion.

In our case, i think we just keep on rolling without a defined "end". The time v1.0 is released is totally undefined, a decision will be very hard.

If we just keep adding features forever, we won't have to face legacy support problems as noone expects a version to be "stable". People will accept that we're moving forward, similar to what Firefox or Systemd are doing.

Other projects like OpenRA just do releases tagged by their date, which is a similar approach, but they also operate independently on planned milestones.

[boombatower]

Version numbers can start with 0. Which indicates incomplete. Having a proper version number does not indicate some sort of support. Firefox provides all kinds of support with huge numbers.

Even things like save files maybe only compatible with specific versions. Are you not intending to have mods possible for this game or extensions or anything else I believe the documentation describes that you do which indicates that you will have to provide some sort of API or method for those extensions to modify things. This implies needing a stable and knowing when backwards incompatible changes are made.

Just like milestones you have to have some sort of goal for what 1.0 would be since your goal seems to be to replicate Age of Empires 2 once you properly support the Age of Empires 2 gameplay that would be 1. Any additional features such as bridges and all that sort of crazy stuff would not be included in that consideration for 1.0 even if they are completed first.

You can choose whatever but given that you expect people to write a AI and mods this definitely seems like a good candidate for semantic version. In fact I would argue that no project is harmed by using semantic versioning it makes things more clear its clean and simple and many packaging and versioning tools are familiar with the format.

I'm curious what Chrome and Firefox will do when they reach version 100 and continue to roll on thru triple digit versions just doesn't seem sustainable, but keep in mind they have very different markets since they are developing extremely rapidly and always adding features with no end in sight. Where as this project has a very specific goal with a lot of fun ideas on the side.

[mic-e]

I'm in favour of using majorrelease.milestone.minorrelease version numbers, for two reasons

• it's best practice, and usually you should follow best practice unless it makes your stuff ugly (such as including full GPL license text headers in every single one of your sourcefiles)
• the major release number can be used to "send signals" to the community/media/... for example we'd bump the major release to 1 once we've fully implemented the age functionality (or whatever).

(the first major release would be milestone 1.0; from then they would be counted as 1.1, 1.2, ...)

[boombatower]

it's best practice

I mean you say that, but evidence seems to point to contrary (milestones is kinda a newish thing, especially the way github presents them...many projects even treat them like beta 1.0.0-milestone1) checkout the Linux kernel...90+% of all linux packages (if not higher), firefox before they copied chrome, any packages releases with things like Composer and related package/dependency managers for other languages...the list goes on. Semver is generally the best practice, but it's your call at the end of the day.

Technically what you suggested is virtually the same, expect for tying to milestones....and not clear if you intend minor to be only for bug fixes?

Major can be used for sending signals in semver as well. On that note >=1.0 typically sends the signal something is ready for normal usage, hence the 0.x.x pattern which things like wine sat in for over a decade (which makes sense). Even firefox and chrome had 1.0 stable for everyone before they went nuts with numbers.

Its undeniable that it needs to be clear when backwards incompatible changes are made for all the reasons above...if nothing more that should be made clear.

If trying to milestones is attractive (especially prior to usable release) then perhaps something like 0.milestone.x util a 1.x makes sense. That way you don't nuke being able to sensibly use semver down the road (since won't have to repeat numbers or start super high), can still tie to milestones (even in semver those are feature additions), and 0.x implies not ready for primetime.

Dunno.

[TheJJ]

Do you all agree that the following is acceptable:

• Until major parts of the game do work, use v0.something
• To keep track of the milestones, we use vxxx.milestone
• Some minor achievements are tagged vxxx.milestone.subachievementcounter

This has the advantage that v1.0 will tell the media that we "finished" something. We'll also take care of the roadmap and we can release early and often by small update releases.

Nyan (#28) and the openage-data repository will have independent versioning to check for compatiblilty of the data pack and files.

Sounds like a plan?

[franciscod]

ship it @TheJJ

[TheJJ]

Should be fixed now.