Starling update to version 2.7?

#21

Haha yeah, I should have specified “before opening a pull request” :slight_smile:
I mean, I don’t know about NPM for example : I don’t use that, don’t know what needs to be done.

Also as Ilja mentionned : who has responsability for updating on haxelib ?

Should I just open a pull request from my latest code (the one that is on par with the as3 version on github) ?
Or should I open a pull request from my “v2.7” branch ? and then the “current” branch ?

Since 2.7 is a starling release, and “current” has changes that are not part of a release ?

Sorry if I over-complexify things, I’d like to do this in a proper and complete way if that makes sense. I would like to put the basic demo online for example, so people can have a quick look if they don’t know what Starling is about. Maybe adapt or create other demos/samples if there is an interest for it etc

Thanks, I was able to merge it (on my side) when I started working on this update so I have it already, hope it doesn’t mess things up :sweat_smile:

#22

For the next release, Joshua would probably need to do it, but Chris and I can be added as contributors for future releases, like we were for Lime and OpenFL.

This is a good question. I would lean toward merging v2.7 first, and then we can release an equivalent 2.7 to Haxelib. Then, the “current” changes can be merged, but we should probably wait until Daniel releases the next AS3 Starling update before we release them to Haxelib too.

Let’s not worry about the npm version right now. We can revisit it in the future.

It should be fine. In my experience, Git is good about realizing that the changes are the same and not a conflict.

#23

That would be great !

I agree 100%, let’s do it like this then. I have a few changes on “current” that should be on “2.7”, I can safely add them there and Git won’t scream when it sees them again in “current” I guess then :slight_smile:

Thanks for your help Josh :wink:

#24

Ok I created both pull requests, I see a few conflicts maybe I should have wait for the second one… :thinking:

#25

Why not adding ChildAccess to openfl Starling? It is a haxe language specific helper class.
It will not be a part of original as3 Starling. So no need to wait for Daniel)

#26

Okay, the v2.7 PR is merged.

3 Likes
#27

It’s still being added, just not part of openfl-starling 2.7, it won’t be there in the haxelib version for now but available from the github repository. I think it’s fine like this no ? I don’t mind if it gets added to 2.7 haxelib though.

#28

It seems safe enough to add ChildAccess to v2.7. We might as well get it in there, since we don’t know when Daniel plans a new release of the AS3 version.

1 Like
#29

Sounds good

issues that can be closed :

2 Likes
#30

When “haxelib update” will see v.2.7?

#31

We are planning small patch releases of Lime and OpenFL with only bug fixes, and we can probably release Starling 2.7 around that time. No specific date targeted yet.

1 Like
#32

There was a slight update to Starling 2.7 just now for anyone interested

you can access

Starling.currentContext (was Starling.context in as3) 
Starling.currentJuggler (was Starling.juggler in as3)
Starling.currentContentScaleFactor (was Starling.contentScaleFactor)

I had to rename since haxe doesn’t let you have a property and a static property with the same name

Mesh’s createDefaultStyle function is now static public like it is in as3

ChildAccess is now in as well

2 Likes
#33

Good news : I learned from Josh that Starling was updated on haxelib ! :partying_face:

2 Likes