I noticed there was a 2.1.7 update for OpenFL on haxelib a few weeks ago, but could not find any good info on what has changed. Are there release notes for the OpenFL releases anywhere? haxelib info openfl gives me a one liner, but it would be great (and professional) to have a proper place to look.
I really like the notes from a release in March that was actually a blog post ( http://www.openfl.org/blog/2014/03/04/new-releases-of-haxe-and-openfl/ ). But it would be awesome to turn it into a section on the website or something. It also advertises all the hard work everyone puts into all the various tools.
I am personally struggling with how to handle version numbers, and how to handle releases. Not struggling, like desperate struggling, but I’d be interested if others have feedback.
Haxelib uses the “SemVar” standard for naming versions, unless I am mistaken, it has three single digits, such as 1.0.0 or 9.1.6. This is nice and clean, but this is not conducive to releasing multiple minor releases, such as 2.1.16 might allow.
If you have a “dev” channel as well as a “stable” or “release” channel, then perhaps you do not need to push official version updates that often. However, as there is no “dev” channel for haxelib, I am inclined to push minor updates frequently, now that we have a build server, and as there tend to be valuable fixes locked up in these minor releases.
I have not written a formal blog post about it, because it is not a major release. We could do a changelog document, I suppose, but I do not know if that is just redundant of the commit log here: https://github.com/openfl/openfl/commits/master
Anyway, feedback on frequency of releases, numbering, and whether we lean more seriously into update mechanisms outside of haxelib (in order to facilitate cutting edge updates and other ways of getting more constant updates), that would be great
I am pretty sure SemVer allows for multi-digit versions for the major, minor, and patch numbers. So 2.1.16 is a perfectly valid SemVer version number. So it does allow for many frequent patch releases. I think Haxelib would benefit from lots of patch releases because it is a relatively stable project feature-wise, but bug fixes are very important to get out quickly.
With a library/tool as big as OpenFL I am not opposed to frequent patch updates, if they are fixing bugs, and not changing the API, then I say go nuts!
The commit logs are probably useful, but personally I find it a bit of a chore to read through. And never really know what commits made it into the current release, or when the previous release starts. But I guess looking at the tags would help a log more: https://github.com/openfl/openfl/commits/2.1.7 .
I just think it is a good opportunity to take these commit messages, and collate quick notes for every release. Even patch releases. Then let the community know exactly what is happening. Until know, I have just blindly done a haxelib upgrade, and not really thought about what has changed because there is no simple way of finding out.
@Hasufel I believe the haxelib.json is what is shown with haxelib info. This really just shows a one liner overview for each version.
Okay, just looked it up. It seems that SemVer does allow for multiple digits, but it enforces no leading zeroes. As a result, you go 0.9.0 to 0.10.0 to 0.11.0, if that was how you did your versioning.
Haxe #if can compare versions, but only as a String, not an integer value. As a result, #if (openfl > "2.0.2") would fail if you had 2.0.10, only with a leading zero would it evaluate as expected.
I suppose one method would be to use more verbose #if statements in that case, or to simply increment the minor release versions as we reach ten patch versions, and focus only on the major version number for big things, hmm
Hmm, I did not think about that problem. It would be really nice if Haxe knew what you meant by
# if (openfl > "2.0.10")
will there be a problem when we get to openfl version 10? (maybe openfl wont get that high, but it may be possible for another lib )
But back to release notes. I think a great Haxe example is HaxeFlixel. They are doing an amazing job. They include a simple changelog markdown file in the repo. This seems very useful, and it is under version control.
HaxeFlixel seems like such a professional library/framework because of details like this. And if it was in version control, I am sure the community could help out a little.
I believe this should cover everything from the first creation of Lime, through to the current version of OpenFL. It omits tool fixes that were made in the lime-tools or aether repositories, perhaps I should include those in the Lime changelog, or just allow those to “disappear”
The tools and the community will be better off because of this.
Very interesting to look back and see all the interesting things that have changed or been fixed. I did not know about a lot of these changes. The community (and of course you Joshua) are really working hard on making OpenFL awesome!
)