PilzAdam wrote:The feature freeze we currently have is quite good, since it forces everyone to actually find and fix bugs. If we just freeze some branches, then everyone will just continue to add new features in other branches, which renders the freeze useless.
PilzAdam wrote:I suggest issues on Github, since they integrate easily in our current communication channels and it's easy to use for every dev.
Linuxdirk wrote:Even if you keep deleting my posts I think you guys really should discuss and merge the pull requests instead of having an argument about versioning :)
hmmmm wrote:… but I agree they are out of place.
hmmmm wrote:Problems that don't get fixed or show up during the feature freeze are left broken until the next release, where there are new bugs.
Linuxdirk wrote:Are they? You mentioned “Minetest hanging in a state perpetual bugginess”. A lot of those pull requests eliminate bugs. Wouldn’t it help to merge them before the feature freeze to prevent the buggyness?
Bugfix releases should be done more often but may need at least two branches.
twoelk wrote:Like some others I do not think the next version should be 1.0.0 or 5.0.0 but rather 0.5.0 and the roadmap adjusted accordingly with a lot of stuff sheduled for 0.5.0 being reassigned for version 1.0.0
And to those comparing version with Minecraft: tell those people to compare with the Pocket Edition, which currently sits at 0.10.4.
As Wuzzy already said above - changing the major number means API breaking changes.
About the -dev patch: Both ways can be correct.
0.4.11-dev -> is not a completed 0.4.11 version, thus in developement
0.4.11-dev -> uses 0.4.11 as base and contains new developement stuff
I personally like the 2nd way.. but this depends on the point of view.
I would prefer to jump to 0.5.0 in the next time when UTF-8 has been added to the game.
What does it matter if the version number irritates anyone now? It'll only happen once, and people can just get over it. The reasoning behind the 5.0 version number was simple: we're at 0.4.11 now, so if the next version would have been 0.4.12...
0.4.12 --> drop the leading zero as so many users are wont to do anyway --> 4.12 --> bump it to 5.0 to start it at a nice round number.
Add a trailing .1, .2, (thus, 5.0.1, 5.0.2, etc.) whenever a new patch release comes out.
From then on, semantic versioning or something substantially similar.
rubenwardy wrote:Pointless.Major.Minor
CWz wrote:would R-*number of release* work too? ie R23,R24
ShadowNinja wrote:It me "x.y.z-dev is x.y.z plus new stuff" seems more intuitive than "x.y.z-dev is what will become x.y.z".
ShadowNinja wrote:Our team would be great if everyone was always around and lived in the same area, […]
ShadowNinja wrote:You need to make Windows MinGW, Windows MSVC, and Android builds, which currently depend on three different people (if I'm not mistaken) which are located in different areas and have different levels of activity.
ShadowNinja wrote:Back-porting significant bug fixes and improvements as a patch release is a good idea too (IMO). This is limited by versioning though of course.
Linuxdirk wrote:ShadowNinja wrote:It me "x.y.z-dev is x.y.z plus new stuff" seems more intuitive than "x.y.z-dev is what will become x.y.z".
Yep :) That’s the only downside of strictly following SemVer rules.
Users browsing this forum: No registered users and 9 guests