Jump to content

Version number system


Xycaleth

Recommended Posts

The first release of OpenJK is nearing completion so we're in the process of deciding how to version it :D I'm thinking OpenJK 1.0 sounds fine, but thinking towards the future, I'm not really sure what would constitute bumping up to 2.0, and what would be 2.1. There's not really much in the way of additional features that would be added to OpenJK because of the very nature of the project. Following that trail of thought, maybe we should use whole numbers instead? OpenJK 1, OpenJK 2, and so on, like Chrome and Firefox do.

 

What are people's thoughts on this?

Boothand and Circa like this
Link to comment

Things that could be considered major that will probably get done at some point that I can think of:

 

(In no specific order)

  • Fix/clean/gut the sound system to split it off to base / OpenAL (use alsoft + EFX)
  • Persistent console history for clients
  • HTTP/FTP download redirection (using cURL) in the client engine.  URL to use set on server
  • IPv6 support
  • Rend2
  • Shared Renderers
  • VOIP support (from ioq3? network compatibility issues somewhat?)  -- Long ways out

Any other things we want to do like re-factoring and splitting stuff off into static libraries to be more shared is too behind the scenes where users aren't going to care so much in terms of bumping big version numbers.

Link to comment

Things that could be considered major that will probably get done at some point that I can think of:

 

(In no specific order)

  • Fix/clean/gut the sound system to split it off to base / OpenAL (use alsoft + EFX)
  • Persistent console history for clients
  • HTTP/FTP download redirection (using cURL) in the client engine.  URL to use set on server
  • IPv6 support
  • Rend2
  • Shared Renderers
  • VOIP support (from ioq3? network compatibility issues somewhat?)  -- Long ways out

Any other things we want to do like re-factoring and splitting stuff off into static libraries to be more shared is too behind the scenes where users aren't going to care so much in terms of bumping big version numbers.

 

Major versions should be kept for major changes like the ones posted above.

.1 decimals for smaller bugfixes

.01 decimals for bugfixes affecting the bugfixes above

 

etc?

Link to comment

We could look at Semantic Versioning, but I'm not sure what constitutes a "public API", we could probably replace that with major changes.

 

JA++ doesn't use versions, it uses git revisions, which are equally as relevant as version numbers.

Link to comment

well, you can browse each individual change made here:

https://github.com/JACoders/OpenJK/commits/master

 

Alternatively, you can view all closed issues here:

https://github.com/JACoders/OpenJK/issues?q=is%3Aissue+is%3Aclosed

The problem with this is the list is massive and people only really want to see the important changes. Or changes that matter to them. Nobody really cares if we removed all the spaces and replaced them with tabs, or fixed some obscure non-standard code. This is why releases should have a change log, like @@Circa mentioned because it lets people see the major changes that has an impact on them, or can benefit them.

 

We could look at Semantic Versioning, but I'm not sure what constitutes a "public API", we could probably replace that with major changes.

 

JA++ doesn't use versions, it uses git revisions, which are equally as relevant as version numbers.

Semantic versioning (I'm assuming you're referring to MAJOR.MINOR.REVISION style, if Google isn't lying to me) is what I default to usually. I guess it depends how much flexibility we want, as in, whether we do something like @@gerbilOFdoom mentioned, with just MAJOR.MINOR, or we have a revision number on the end.

 

I'm not terribly fond of using the git revision. It makes it difficult to compare versions, and it doesn't let people know whether it's a big change or not. It's easier to see from comparing 1.4 and 2.0, that 2.0 probably has a big change compared to 1.4. Whereas if you have ea863fb and 87048bac you don't know if one comes before the other, or if it's a major or minor change.

 

I think I'm leaning towards major.minor.revision at the moment just cause it gives us flexibility, and I guess we don't have to use the revision number if we don't have any tiny changes. Plus I hadn't thought of all those major changes that we have yet to do :P

eezstreet likes this
Link to comment

And remember that you're releasing this to the public, not other coders. A change log with user friendly descriptions will be the way to go. I've noticed many times that those issues on GitHub have lots of wording and terms that might as well be a foreign language to me and most others. Even some support topics made here have that problem.

 

I could get into this more later and in a different thread, but just remember to keep a noob in mind when going forward from here. :)

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...