Xycaleth Posted February 7, 2015 Share Posted February 7, 2015 The first release of OpenJK is nearing completion so we're in the process of deciding how to version it 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? Circa and Boothand like this Link to comment
DT. Posted February 7, 2015 Share Posted February 7, 2015 Using 1.x etc allows room for fixes in the decimal spot. Or you could do 1a, 1b etc. Link to comment
gerbilOFdoom Posted February 7, 2015 Share Posted February 7, 2015 Version number for significant upgrades, revision number for fixes. Improve performance, make coding easier, finish rend2, etc. would be a new version number. Fix textures for certain NPCs not appearing or cause Rosh to die of lightning bolts whenever he exists? Revision number. DT., Xycaleth and Boothand like this Link to comment
DT. Posted February 7, 2015 Share Posted February 7, 2015 ^ This sounds alot better than my suggestion. Link to comment
ensiform Posted February 7, 2015 Share Posted February 7, 2015 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 clientsHTTP/FTP download redirection (using cURL) in the client engine. URL to use set on serverIPv6 supportRend2Shared RenderersVOIP support (from ioq3? network compatibility issues somewhat?) -- Long ways outAny 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
gerbilOFdoom Posted February 8, 2015 Share Posted February 8, 2015 Could keep a separate code revision history and maintain a separate changelog for it. Keeping modders up to date on the significant changes to OpenJK's source would probably be appreciated. Link to comment
Circa Posted February 8, 2015 Share Posted February 8, 2015 Agreed, change logs would be super nice for the official releases. I'm glad to hear its nearing first release! Xycaleth likes this Link to comment
eezstreet Posted February 8, 2015 Share Posted February 8, 2015 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 Link to comment
Shadzy Posted February 8, 2015 Share Posted February 8, 2015 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 clientsHTTP/FTP download redirection (using cURL) in the client engine. URL to use set on serverIPv6 supportRend2Shared RenderersVOIP support (from ioq3? network compatibility issues somewhat?) -- Long ways outAny 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
Raz0r Posted February 8, 2015 Share Posted February 8, 2015 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
Xycaleth Posted February 8, 2015 Author Share Posted February 8, 2015 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%3AclosedThe 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 eezstreet likes this Link to comment
Circa Posted February 8, 2015 Share Posted February 8, 2015 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
Xycaleth Posted February 8, 2015 Author Share Posted February 8, 2015 Don't worry, we (or at least I) will make sure that all the 'player-facing' material for the release is in non-coding speak Circa likes this Link to comment
Futuza Posted February 9, 2015 Share Posted February 9, 2015 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?I'm a fan of this idea. Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now