Haxelib release of 4.0.0

[Tiago-Ling]

Hey guys, with the recent closure on #1471 by @larsiusprime i think it's a good time to schedule a definitive date for releasing a stable version to haxelib.

Comparing the latest release on haxelib (3.3.11) to what we have now on dev, i think it's much better and even stable than before.

There may be some issues left to solve, and it would be great if we could list them here. Ideally these issues would be only bugs, and only "game-breaking" ones.

An idea would be to take advantage of @Beeblerox 's presence here to solve the worst problems and then make the release in ~2 weeks.

What do you think?

[larsiusprime]

Wow, 2 weeks!

I mean, I'm all for releasing 4.0.0, I think we really need to put a stable version of the dev branch out. That said, besides dealing with bugs I think we owe it to our community to prepare people for the breaking changes, so documentation is going to be as important as the code quality itself. We'll need, at minimum:

• A comprehensive changelog
• A comprehensive upgrade guide
• A set of upgrade scripts for certain changes that can be automated? ("nice to have")

[Tiago-Ling]

Ok, 2 weeks is probably way too soon.

And i agree with you, the biggest problem is the lot of breaking changes that'll cause. Also, most contributors seem to use dev exclusively - i for one do not remember anything of the old api.

But i also figure that a clean release with no pain whatsoever for the users will be impossible at this point. There's simply too many changes since the last version and they'll inevitably cause some trouble for people upgrading.

For the guide i think comparing the flixel demos 1.1.2 to the current ones would be one way to go. The guide does not need to 100% complete also: after the release, users will still find incompatibilities but as they get solved they'll added to the guide.

[Gama11]

I don't think 2 weeks is viable at all. No reason to rush it after this much time.

I don't know how long @JoeCreates needs to solve #1087 - once that's done, it needs to be reviewed tested, etc... And that's just one of the unresolved issues (although maybe the biggest one).

I don't know if @Beeblerox plans to have #1575 in 4.0.0. Though it doesn't matter much if it doesn't have breaking changes.

Checking all the demos for regressions will take time. So will updating all the docs and demo .swf files on the homepage, writing a release blog post, upgrade guide etc etc... I'm kinda busy atm.

[larsiusprime]

These are both good comments. I think rather than committing to a date we just need to commit to the idea that a release is actually really happening. Move it from the mental space of "some day..." to "reasonably soon."

Start making some issues and plans towards that goal, figure out everything that needs to be done to make it happen, start working through it, and then only commit to a date once we have a very good feel for how fast we're progressing.

And I agree that committing to a 100% painless upgrade is impossible. This is a breaking change release, and as far as I can tell, it's by design -- we kind of intentionally put as many breaking changes in as we could so that we wouldn't be dropping them one by one in subsequent releases.

So our responsibility is to provide as much documentation and help as we are reasonably able (complete 100% coverage likely being "not reasonable"), and not over-promise that people won't have to refactor their code.

I think a big part of easing the transition is just some useful advice in a FAQ. Like:

Q: Should I upgrade to Flixel 4.0.0? A: Not necessarily! If you have all the features you need, just finish your current game in Flixel 3.x, and wait until your next one to move to Flixel 4.0.0.

Etc.

[Tiago-Ling]

One idea would be to create a "4.0.0 release" label and put it on issues that should be prioritized. Bounties could also be set on the nastiest ones.

[larsiusprime]

@Tiago-Ling An excellent starting point. And I think we have a 4.0.0 milestone already, too?

[Tiago-Ling]

@larsiusprime Looking at the list there is a lot of stuff to be done yet. Maybe some of the less critical (improvements or new features / questions) could be moved to a subsequent release?

Also, i'm not trying to impose a date or to rush things out, mostly trying to understand things. :)

And yeah, seeing the whole picture made me realize how insane my 2 weeks date was.

[larsiusprime]

No worries; this is how the software development train works. Basically what we need to do right now is just bring the contributors together and have a conversation about this and see what we can and can't do.

Once the major contributors have given us their feedback on the current state of things we can start looking into triaging features for the release (assuming we have a consensus on the release).

[sruloart]

• Things are a bit slow here ATM since @Gama11 can't give his full mighty attention, and @Beeblerox does his best to handle rendering issues but I don't see how stuff can be improved unless some boundaries are removed (like, allowing contributers to commit breaking changes, asking contributers to commit maintenance changes, asking for more people to get involved as active contributers). It's a bit risky but I prefer risky to stagnant, a few people can't be expected to do all of the work all of the time (though most Haxe libraries are handled exactly like that).
• Anyhow, release requires a lot of effort, it's not just about code. I think, as things stand, 2016 is more likely than the next month.
• Talking about documentation, maybe we can steal the Haxe Manual Github set-up and have a proper HaxeFlixel manual? :) users dig manuals, they don't dig long changelogs...
• Also this release campaign should include the new Patreon option, would give it a nice boost I think. It would be cool if one day HaxeFlixel can afford to pay bounties and have a proper forum.

[MSGhero]

If stage3d doesn't break anything, it could be slid in for a minor release. Plugins are huge and should be done for 4. If we can figure out what to do for #1593 and implement it soon, then that should be there too (so we don't have another breaking change a month after 4).

I'm on my phone now so idk if it's like this already, but haxe did a bunch of milestone stuff for 3.2 to focus in on those issues.

[Tembac]

These are great news!

I can't help with code but maybe with documentation and testing. Let me know what is needed. Also, I'll try to gather people from our Latin America community to help.

[AndreiRegiani]

As a developer using HaxeFlixel for commercial and company projects, the most important thing I need now is stability for the build process. This is all I'd wish for the 4.0 release. I think the community outside GitHub are the ones who most suffer from this instability.

In the previous months I've seen many people having lime setup or build issues, such as https://github.com/openfl/lime/issues/610, this is actually not a HaxeFlixel issue, but right now anyone being a HaxeFlixel developer means each of us could be using different version of Haxe, OpenFL, HaxeFlixel, haxelib, and more.

What is suggest is to make 4.0 the most stable and long-term supported release. We need to unify every end-user under the same versions, for this we need a standalone HaxeFlixel distribution (automatic installer), it will install the tested version of Haxe, OpenFL and dependencies, the beginner doesn't need to worry about the whole stack anyway.

So the first thing to do is to decide what versions are working well for the dev branch, and make installers for each platform, I can do for Linux and Mac, a simple .sh script can install everything, this is what should be on the webpage instead of letting the user install latest versions of OpenFL/lime.

[MSGhero]

@AndreiRegiani that's a good point, especially considering flixel is the most popular game-making haxelib (ignoring openfl and lime) and is being used a lot more in ludum dare. The install script would literally just be the travis script, with the build versions of haxe/flixel/lime/openfl/hxcpp all held constant until a significant upgrade comes around for any of those.

[sruloart]

@AndreiRegiani @MSGhero I think it's much easier to add to the tools a command like haxeflixel setup [target] and let it install the best possible releases of OpenFL and Lime to fit the current HaxeFlixel version.

However, I'm not against a simple multi-stage installer to make the life of the user a little more simple (install haxe if it's not already installed, then install FlashDevelop if it's not already installed, then haxelib install flixel, then run the setup command I've mentioned). If we're at it, one can use a small executable to create a template instead of using the command line directly.

[larsiusprime]

I do think a curated installer is a good idea. There's enough moving pieces to this that the more we can simplify the stack for beginners, the better. Advanced users can always do all the haxelib-fu and git magic they want.

[FlorianBT]

I'll just put my two cents in :)

I agree with @larsiusprime here, I think an installer would do more harm than good. I am not coding with Haxe for long, and I remember pretty well what I found hard to deal with, and the install process is not, imo. In fact, using an installer would "hide" the whole library installation / fetching process, and make the whole thing more opaque to the user. I think it is very important for the devs to know all/most of the libraries used, why and where.

Lately I had hard times making a HTML5 game, as I had to dive into some libs, modify some code on dev branches, and so on. Now I am back on a cpp/desktop project, I found things so much clearer and easier. If I have an issue, the first thing I do is looking at the incriminated library github page and manual. Then looking directly at the code, and checking if the issue is persistent through different versions. This is a gymnastic I can do easily now I have put my hands in the dirt and played with the libs (command lines, project.xml, and so on).

Hiding all this behind a double-clickable executable or sh script would help newcomers up to a point. Once they reach it, the lack of practice with command line tools and external libraries will make their work harder. It would be more helpful to better document what is needed for what and make project-setup-tutorials per platform/use-case, in my humble opinion.

[larsiusprime]

To be clear I'm actually for a curated installer, not against :)

I would take inspiration from Netflix's new OSS strategy: http://techblog.netflix.com/2015/10/evolution-of-open-source-at-netflix.html

IE, make it easy to get started and play around with things, and then provide clear documentation for advanced use and how everything fits together. Most users will eventually need to understand more about how the stack works, but IMHO that initial 30 minutes of onboarding is crucial and if someone has to fight all day with the stack to run a simple sample, they'll probably just move on.

[FlorianBT]

I read I don't instead of I do in your post... My bad. I am against any opaque installer. If the install process is transparent, then why not. But to be able to play around with things and run samples, the user needs to know what to play with and where to find it (and eventually what use it has, if it is not obvious).

I must admit I am quite phobic with installers (windows style), bulky you-dont-know-what-is-happening-but-it-is-fine-I-swear procedures. But anything other than that could do, kinda.

[Tiago-Ling]

@FlorianBT That's not a good reason to not provide this option for other people. Keep in mind that the "traditional" install method would always be available and would be the same: the same pages, descriptions and everything else that flixel already have would be there.

The difference would be that a link to the installer would also be provided and the user would be able to choose what is best for him/her.

I don't have any hard evidence but i think there's more people fond of installers than otherwise. One of the great strengths of HaxeFlixel is exactly the ease of use to create a simple game: fewer lines of code, fewer sub-systems that have to be implemented and voilá, everything is on the screen, working on multiple targets. Many libraries and frameworks have much slower workflows, especially in other languages. One could argue that using flixel vs. other libraries is kind of similar to using an installer vs. doing everything manually.

Anyway, my 2 cents.

[FlorianBT]

Makes sense. It's not as if everyone was forced to use it. Looks a lot more appealing put like this, you've convinced me :)

Le jeu. 29 oct. 2015 à 14:31, Tiago Ling Alexandre notifications@github.com a écrit :

@FlorianBT https://github.com/FlorianBT That's is not a good reason to not provide this option for other people. Keep in mind that the "traditional" install method would always be available and would be the same: the same pages, descriptions and everything else that flixel already have would be there.

The difference would be that a link to the installer would also be provided and the user would be able to choose what is best for him/her.

I don't have any hard evidence but i think there's more people fond of installers than otherwise. One of the great strengths of HaxeFlixel is exactly the ease of use to create a simple game: fewer lines of code, fewer sub-systems that have to be implemented and voilá, everything is on the screen, working on multiple targets. Many libraries and frameworks have much slower workflows, especially in other languages. One could argue that using flixel vs. other libraries is kind of similar to using an installer vs. doing everything manually.

Anyway, my 2 cents.

— Reply to this email directly or view it on GitHub https://github.com/HaxeFlixel/flixel/issues/1600#issuecomment-152179345.

[MSGhero]

Should there be a version before 4.0.0 with cherrypicked commits? Like 3.4.0 or whatever the next minor version is.

[Gama11]

Given how many changes there are, a new minor version (implying new features) is not really feasible, or at least doesn't seem worthwhile. There have been a number of patches with bugfixes though - another one might be necessary since the latest Lime / OpenFL releases had some breaking changes.

[MintPaw]

Man, I had to go back to master to use babylonhx, and wow master is behind. No update(elapsed), no loadMapAsCSV(), the release should probably be broken up a merged in more branches like a FlxTilemap refactor, similar to how the collision refactor is now.

[01010111]

I don't know if I can contribute to code, but I am more than willing to commit to helping things move along by updating demos, writing guides, etc.

I try to be a big haxeflixel evangelist, and I prefer to proselytize folks to the dev version, but so many people don't want to work with an unstable release. I'm really excited for it to be ready!

[Gama11]

@MintPaw Why does babylonhx depend on the master branch of flixel?

[MintPaw]

@Gama11 There's several ways to compile babylonhx projects using Snow, Lime, Openfl, etc. I prefer Openfl because of the telemetry. The Openfl version does depend on HaxeFlixel. I didn't do a lot of debugging to figure out what was wrong with the dev version. It wouldn't be a problem if master wasn't 6 months out of date, it's like working with two completely separate code bases.

[gamedevsam]

New deadline: MagFest (Feb 18th). I expect to see an uptick in user adoption afterwards, since I'll be there and sharing the word (plus other people will as well), so I think that's a good date to aim for.

[IBwWG]

Has anyone happened to start an upgrade guide already? I could use one, since the current release has a bit of deal-breaker bugs in it for me, and I'm encountering a number of issues even on my tiny codebase trying to migrate it to compile with the dev branch.

If there isn't one, maybe I could help start one, except that since I'm new I have no idea yet about the intentions behind various changes. Maybe someone who has been around can do a Q&A session with me--that would help me migrate my code and understand The New Way of Doing Things, while also kickstarting the upgrade guide.

[IBwWG]

Congrats! :)

[gamedevsam]

Here's the upgrade guide.

I'm also thinking an easy to use installer would be a wise investment for the long term success of HaxeFlixel. There are several cross platform open source game engines out there, and it hasn't been clear to me what is HaxeFlixel's main competitive advantage is. After discussing with @01010111 at MagFest, it dawned on me that HaxeFlixel could (and should) be the easiest engine to set up and use, regardless of what platform you want to develop on, or deploy to.

Flash Flixel was hugely popular because it was so easy to set up and use. HaxeFlixel is not THAT complicated to set up, but any friction we could remove from the setup process might result in more aspiring programmers making games and engaging with our code and community.

I need to talk to @larsiusprime and @Gama11, but it's likely I will be using Patreon moneys to incentivize the development of an easy to use installer.