Release version 2.56

[Dovyski]

This issue lists all tasks we need to finish in order to ship version _2.56_.

• [x] Test current build, merging pull requests with any regression fix;
• [x] Update CHANGELOG file;
• [x] Merge dev into master
• [x] Update flixelcommunity.org with lastest build info;
• [x] Spread the word and celebrate :D :cake:

[Dovyski]

I've just sent two pull requests with regression fixes: https://github.com/FlixelCommunity/flixel/pull/181 and https://github.com/FlixelCommunity/flixel/pull/180. I've tested the current dev branch against three of my games:

• BlacksmithDash
• Station Siege
• Madly Angry Cat

Excluding the regressions I've fixed, Flixel Community worked pretty fine out of the box (it even helped me find a non-existent frame in a sprite). Congrats everyone!

[WingEraser]

Run Mode before you release. It doesn't run as expected.

[Dovyski]

@WingEraser We will and thanks for all the feedback and help! I didn't have time to check your pull requests or Mode , but it's on my list.

[IQAndreas]

Update CHANGELOG file;

Picture me saying this like a 6-year-old who was just told to clean his room: "Do we have to?"

Since we don't have any new features (pretty much only bugfixes), can't we just point users to the list of commits? ;)

But if a changelog is needed (and I would actually be glad to do the dirty work and write it), I have been playing around with labels and milestones in such a way that it should be as simple as going through this list and copying the information over:

• https://github.com/FlixelCommunity/flixel/issues?milestone=1&labels=pull+request&page=1&state=closed

Also, how detailed should a changelog be? New features are always good to include, but a list like "The following 42 bugs were fixed:" isn't all that useful to someone who never ran into any of them, or someone wanting to update to the new Flixel version and want to see if they need to change their own code in any way.

[Dovyski]

Run Mode before you release. It doesn't run as expected.

Mode's menu does not work because we set moves = false in FlxText. I've fixed that in https://github.com/FlixelCommunity/flixel/pull/180, but @moly pointed out that FlxObject documentation states that FlxText has moves defaulted to false.

If we decide to keep moves untouched in FlxText (the original buggy behavior), we must update FlxObjects documentation to reflect that.

Since we don't have any new features (pretty much only bugfixes), can't we just point users to the list of commits? ;)

I see your point, but that's not polite :D Personally I always look at the changelogs to check if everything I use will continue to work, or to have a minimum understanding of what has changed. We don't need a changelog listing all bugs that were fixed, we can condense them, e.g.:

Fixed several bugs regarding FlxTilemap

If a developer gives Flixel Community a try and it doesn't work for his game, the changelog will give him a hint: "Oh, I use FlxTilemap, maybe they have changed something I was relying on". That's the real meaning of a changelog for me.

But if a changelog is needed (and I would actually be glad to do the dirty work and write it), I have been playing around with labels and milestones in such a way that it should be as simple as going through this list and copying the information over:

That's perfect! We can condense issues targeting the same class, such as the FlxTilemap I previously described.

[IQAndreas]

This is the gist of the changelog. I still need to clean it up and make it look a bit prettier. Also, there are a few last changes on their way.

Do you guys have any thoughts? Anything that should be moved/removed?

---

New Features

Add properties numFrames and maxFrames to FlxSprite #174 Add new FlxTween class #114 Add function to trigger full-screen support (not complete) #74 Make FlxG.log() able to split out arrays using FlxU.formatArray() #74 Add optional ColorMap parameter to FlxTilemap.bitmapToCSV() #74

Improvements

Prevent being able to set a FlxSprite to an invalid frame #174 Prevent errors if destroy() is called twice #153 Log error if invalid Bitmap passed to FlxG.addBitmap() #127 FlxG.sort() won't crash if a property is not found #116 Log error if invalid custom particle class is passed to FlxEmitter #95 Prevent being able to pass null to FlxObject.add() #87 FlxObjects will now stop when they reach the end of a path #85 Remove several FlashBuilder/FDT warnings Remove migration warnings if published with Flash IDE #76 Add super.destroy() to all overridden destroy() methods #73 Add http:// prefix if user did not in FlxPreloader.goToMyURL() #71

Performance Improvements

No need to fill a camera twice if not blending alpha #143 Remove small performance issue in FlxG.addBitamp() #96 Refactored FlxObject::preUpdate() to remove uneccessary code #82

Bugfixes

Fix FlxGroup#maxSize #184 Fix documentation for FlxText#moves #180 Fix FlxSprite.drawLine() incorrect behavior when full transparency set in color #173 Fix FlxTilemap.overlapsWithCallback calls callback when no overlapping #166 Fix FlxCamera "jitters" when following a target #134 Fix FlxText and problem with camera zoom #119 Fix Mouse.as doesn't like negative cursor offsets mixed with native Flash #117 Major cleanup and bug fixing of FlxSound #114, #103, #101, #92, #80 Fix FlxObject#(overlaps|overlapsAt) checking only first element of FlxGroup #109 Fix FlxTilemap not clearing variables before loadMap #102 Fix overlapProcessed isn't properly cleared in FlxQuadTree #100 Fix FlxTilemap ignoring last tiles if startingIndex > 0 #99 Add missing usage of particleClass in FlxEmitter #95 Fix FlxTilemap.ray() result value always null #84 Fix FlxU.round() giving incorrect results for negative numbers #79 Fix FlxU.formatArray() includes first element twice #77 Fix health only initialized in FlxSprite, should have been in FlxObject #74 Fix incorrect value for moves in FlxTileblock and FlxTilemap #70

Should these be in the changelog?

Move source to src folder Remove documentation (only include it in release builds) Add generate-asdoc.sh and generate-swc.sh utilities Add .gitignore

[Dovyski]

That's great, well done! About your last question, I think it's important to include these entries:

Move source to src folder Remove documentation (only include it in release builds)

[Dovyski]

We are almost there! :D

As soon as we review and merge the last pending pull request (regarding the offset by 1 in STYLE_LOCKON), we can focus on the tasks here. Flixel Community website is ready (I've made a small facelift), only the download links are "wrong" (we must merge dev into master before I can fix them).

[IQAndreas]

dev merged into master at 98f01d388b74ee690e47ea71eb80ac877ecd438b

Now I just need to (sorry it's taking so long, there were bugs in the automatic build script which for some reason weren't appearing when I ran it last time).

[IQAndreas]

It is complete!!

There are two ways we could release Flixel (I uploaded files to both so we can play around with them and see what we like):

The old way

As I have done before, I pushed everything to the following repo:

• https://github.com/FlixelCommunity/flixel-release

Each "category" can be found in a separate branch (and GitHub also generates download links for each type):

• release - Contains everything, the source code, the SWC, and the documentation, all in one archive (view, ZIP)
• bin - Contains the compiled SWC of that flixel version (since it is in a repo, it can be added as an easy-to-update submodule like in the sandbox (view, DOWNLOAD)
• docs - Contains the flixel documentation. We should either copy this over to or add it as a submodule in the website (view, ZIP)

I'm rather proud of the fact that I make all of these by editing the version number in the utils/config file and run utils/build-complete-flixel-release.sh, all the generating and uploading is done automagically. (source)

The new way

See the following page (and the necessary links can be found on that page, though I can't seem to add descriptions to the downloads):

• Flixel v2.56

It's fancy, and clear, plus it looks nice when you have a list of all available releases (though I still need to add the binaries etc to the other versions):

• Flixel releases

Sadly, this way requires some manual fiddling, however, when combined with the automated scripts I have been using, the amount of manual work is still very minimal. I might even be able to hook into the GitHub API and upload the files automatically there too.

[IQAndreas]

The final bug has been fixed and merged. Now all that is left is the website and cake.

After some consideration, I think I will scrap the "old" way of doing things and instead use GitHub's new release system. I can handle some manual uploading.

I haven't uploaded the latest builds yet, however, the links to them will be identical to the links currently on the release page (so you can go ahead and add the links to the site, and they will still be valid after I replace the old builds):

• Flixel v2.56

[IQAndreas]

Done! Flixel v2.56 builds have been uploaded:

• Flixel v2.56 - The full package; contains the source, compiled SWC, documentation, and other files (README, LICENSE, and CHANGELOG).
• Flixel v2.56 SWC
• Flixel v2.56 Documentation

[Dovyski]

Website updated, all set, it's time to celebrate! :tada:

Congratulations to everyone involved! It took us some time to discuss all those issues (and iron out all their bugs), but we did it. Now it's time to dive for more awesome features!

And the so promised cake :smiley:

[WingEraser]

:smile: Now forum announcement and let Adam know about it.

[greysondn]

I think I have two pulls from the previous version, with the old layout (assuming the change actually happened)... GIT has the ability to resolve merges where files have relocated last I checked and I offered to update those once the release happened as a base for work others wished to do (and to complete work in them).

Would it help the community for me to handle the merge from upstream down to my changes and then submit changes back upstream in those requests?

Perhaps this isn't the best place to ask.

Edit:

I went ahead and made an attempt at #160. Granted those changes aren't overly significant anyhow. It's untested code, however, and may have unintentionally created a mess. The change is making problems in my fork, which doesn't surprise or upset me overly much. Just makes me feel tired.

169 is on my todo list.

I'll be busy until early December due to the holiday and the need to cram work into our schedule immediately after it. But I guess here's a sign of life to show that my inept, long-winded, and often silly self is still here wanting to help :wolf:

Edit2:

Yay on the new incremental, by the way, ladies and gentlemen :+1:

[IQAndreas]

But I guess here's a sign of life to show that my inept, long-winded, and often silly self is still here wanting to help

And it is appreciated! It is normal for many (and I must confess I have been guilty of this myself) to send an issue or pull request to a project, then disappear without it being resolved properly. Kudos to you for sticking around. :)

I just apologize that I'm putting you through so much extra work having to re-do the commits, but just say the word and I will give a hand.

[IQAndreas]

I started a thread on the Flixel forums:

• FlixelCommunity v2.56 (Flixel v2.55 without the bugs)

Let me know I should adjust the title or any of the content.