Flashpunk and Stage3D

(MartĂ­ Angelats i Ribera) #1

I just realized that we were talking about this in the wrong thread. This thread is to talk about stage3D with FP.

Merge HaxePunk with FlashPunk?
(mikale) #2

Woop!! Hopefully we can get the ball rolling on this.

(MartĂ­ Angelats i Ribera) #3

With this change the version should change right? Would it be 1.7.3? 1.8.0?

(Zachary Lewis) #4

Since FlashPunk is using Semantic Versioning, we’d get a minor version bump if we add new functionality but retain backwards compatibility. 1.8.0 should do the trick.

(MartĂ­ Angelats i Ribera) #5

I have another technical question about how much can i modify.

The problem is that i need to modify some Screen functions making them in another class. Would that be considered losing the compativility? I mean they are public functions but i’m not sure if they are really used outside the library.

(Jacob Albano) #6

If you do any of the following:

  • Remove a class
  • Remove a public, protected, or internal method or property from a class
  • Change the signature of a method (the parameters, their types, or the return type)
  • Change the behavior of a method so that it results in a different outcome

you’ve broken compatibility.

Even if you don’t think a method is used often, removing or moving it breaks compatibility, and that’s not okay. It’s important that all future revisions of Flashpunk be compatible with older games which use it, within the same major version of course.

(Zachary Lewis) #7

My impression from reading the documentation for semver is that version changes correspond with API compatibility, not necessarily the content of the framework.

Here’s an FAQ from the documentation.

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

@Copying It’s important to note the distinction between being “buildable” and “compatible.” If you make a change that causes the screen origin to be at the bottom-left corner of the screen instead of the top-left, that change would probably allow for older games to build just fine; however, they would be “broken” by that API change, because they were originally developed under the assumption that the origin was at the top-left.

Just use common sense when making changes. If you’re worried about breaking compatibility, just ask us and we’ll take a look at it. The easiest way would probably to just share a link to your commit on Github, like so:

(MartĂ­ Angelats i Ribera) #8

I think i’ll save that functions with a note saying that there is a better way of doing it, and making that function do that.

@jacobalbano I didn’t know that the internal method/property from a class was . I thought they ould only be excessed by other parts of the library, so modifying them wouldn’t modify the “final result”.

@zachwlewis My github righ now is a mess. I think i have to clean it up. Anyways if i need to show you some code i’ll do it this way.

(Jacob Albano) #9

Protected items have to stay the same because of overrides. Internal could technically be changed but I’d avoid it if possible. At that point it’s not about breaking the build, it’s about making it difficult on other developers who may be familiar with the current codebase. Again, common sense.