Is it ok to name v4 with metal-support?

Is it ok to name v4 with metal-support?
0

#1

Cocos2d-x is supporting metal. It will break some API after finished. We need to have a version name to distinguish it clearly, so i think 3.18 is not a suitable name. But i am not sure if v4 is suitable or not, because it doesn’t bring more features. There is another selection, that named v3.20. What’s your opinion?

  • v3.18
  • v4
  • v3.20

0 voters


Metal support alpha0 version released
pinned globally #2

#3

Well, if it breaks some APIs then name should be very different. Anyway, how much does it break?


#4

Maybe v3.33? :slight_smile: Easy to remember.


#5

Honest question: Who cares?

Does it make a difference at all?


#6

Just see https://semver.org/ and you understand, why developer should care about version numbers.


#7

I still do not understand.

Look at the link, it calls for 4.0 immediately.

If the version numbers by cocos are made with this scheme then there is no discussion at all.


#8

In a typical scenario, yes, 4.0 would be the correct and obvious version number to go to, but I’ll explain why I personally chose 3.20 in this specific instance.

The reasons are:

  1. Cocos2d-x 3.x has broken the API before (I’m almost certain of this, but I could be wrong).
  2. If developers want to have their apps running on iPhone or Macs when OpenGL support is removed, then there will be no choice in the matter, as they would have to move to the new version with Metal support, API breakage or not. Whether the new version is 3.18, 3.20 or 4.0 won’t matter, and if it is 4.0, then the 3.xx branch becomes obsolete, and will serve no purpose (unless the developer doesn’t want to support Apple products).
  3. Originally planned changes to 4.0 would break the API anyway, and if 4.0 is chosen for Metal support, then the next API breaking release must be 5.0, so we don’t get into the same situation as mentioned in point 1 (where minor version updates break the API).

For those reasons alone, it seems pointless to move to do a major version number change in this specific instance.

If the decision is to go with 4.0, then great, as long as this versioning system is adhered to, so that any future API breaking changes must be a major version increment.


#9

The version is temporary, we can modify it before releasing.


#10

It breaks APIs related with rendering, and i also remove deprecated API.


#11

Hi , what is “metal” ? Could you give some information regarding “metal” ?


#12

It is the apple’s graphic API. You can get more detail information here: https://developer.apple.com/metal/.


#13

I just wondering, how many active developers and how many decides this?

Looks like up to 50 ppl here, means active is no more than a couple of thousands, who still using this engine?


#14

@zhangxm I think making it 4.0 will be best simply because of the braking API changes based on https://semver.org/

It’s easy for someone who doesn’t read these post and is using v3 to believe that they can upgrade to a 3.18 or 3.20 since it using the same major version and then complain that their project doesn’t work.

Also, even if Cocos2d-x made braking API changes in minor or patch releases in the past, This can be a fresh start to making things standard! :slight_smile:

I know it’s not easy and the community can be restless but thanks Cocos2d-x team for all your hard work on this stuff. Can’t wait for v4 (Hopefully!:crossed_fingers:)


#15

Thanks for your suggestion.


#16

Because of that i would have named Cocos Creator with 3D Support something like "Cocos Creator 3D v1.0" or “Cocos Creator Plus v1.0”. If Cocos Creator 2.0.x won’t get any updates anymore, then it’s okay that the 3D version get’s just another minor version.

But sometimes it’s better to set a clear cut. So “Cocos2d-x v4” is the better choice.


#18

V4 :smiley: