We need milestones

[AbelToy]

We need milestones here in Issues.

We should plan, at least:

FlashPunk 1.7.3 - when is this going to be released guys? 1.7.2 was almost half a year ago!
FlashPunk 1.7.X - What's missing?
FlashPunk 1.8 - Aw yeah
FlashPunk 2.0 - Aaaaaaaaw yeaaaaaaah.

(also, unrelated. I'm not a collaborator anymore. What happened? Who are the new guuuuuys)

[zachwlewis]

Keep in mind that we're using Semantic Versioning.

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

That said, any bugs we fixed should be rolled into 1.7.3. If we make any backward-compatible additions (like new hitboxes), we'll release 1.8.0. If we break anything (like tweens), we'll release 2.0.0.

[AbelToy]

We should prepare more stuff for 2.0.0 though, can't be anticlimatic.

And creating the milestones here in Issues helps us visualize and motivate ourselves!

[zachwlewis]

We should prepare more stuff for 2.0.0 though, can't be anticlimatic.

That's not really how semantic versioning works, though. It's supposed to, at a glance, let you know if your code will be compatible with the library.

[AbelToy]

It doesn't forbid us to do that, though... we just need a list of issues (feature suggestions and stuff) marked as milestone 2.0, which can break stuff, and when they're done, we tag it as 2.0.0. What'd be the problem?

[zachwlewis]

If we have lots of updates, that's great! There's no problem with doing it like that, I'm just letting you know that the title 2.0.0 doesn't have to be brand-spanking-new.

I think we might fix tweens and pull @azrafe7's polygon hit boxes into 2.0.0. That would be a pretty sweet release.

[AbelToy]

yeah, the collisions is pretty much a good selling point for flashpunk 2.0. So can we safely say the implementation can break api compatibility? So what about using this to improve the rest of the collision API as well?

[zachwlewis]

What is wrong with the rest of the collision?

I'm not sure if the collision change actually needs a major version bump. I'll have to look and see if there are any API changes that aren't backwards compatible.

On Tue, May 20, 2014 at 5:08 PM, Abel Toy notifications@github.com
wrote:

yeah, the collisions is pretty much a good selling point for flashpunk 2.0. So can we safely say the implementation can break api compatibility? So what about using this to improve the rest of the collision API as well?

Reply to this email directly or view it on GitHub:
#139 (comment)

[AbelToy]

Basically, I think the Hitbox is just weird (it changes properties of Entity) and some of the collision code looks very hacky to me...

@azrafe7 What would you add in your collision changes if you could break the api entirely?

[azrafe7]

I'd say to stick with what we have for now, as it's proved sound till this moment.

Although a bit convoluted the collision works pretty well as it is (also thanks to many fixes across the years). At some point I considered rewriting it from scratch to make it more simple and mantainable, but that's too BIG of an undertaking and will surely break other things in the framework.

Indeed it would be interesting to follow the path taken by Phaser, which supports multiple collision systems (with or without physics - default, Nape, N, etc.). But obviously that too would take some real commitment to code and integrate into FlashPunk.

The one thing I'd really like to see in FlashPunk (that shouldn't even break compatibility) is some space partitioning datastructure to aid in resolving collisions faster. I don't like quadtrees, but I've recently discovered RTrees. They're really powerful and am planning to make an implementation of them (no code to show yet).

[zachwlewis]

No, no, no… Stop trying to break stuff just to get a pretty number. Don't worry about the version number and worry about fixes and improvements.

On Wed, May 21, 2014 at 3:07 AM, Abel Toy notifications@github.com
wrote:

@azrafe7 What would you add in your collision changes if you could break the api entirely?

Reply to this email directly or view it on GitHub:
#139 (comment)

[AbelToy]

Okay, fine... hahaha.

[tadeubas]

@Rolpege , see: http://semver.org/
Plz read Summary and FAQ at least 😃

[AbelToy]

I've read Semver a few times already.

I just don't find the idea of quickly having version 14.2 that attractive...