need release versioning about vita-headers

[yne]

@gnuton https://forums.docker.com/t/does-docker-hub-have-a-size-limitation-on-repos-or-images/10154/2
I also prefer human-made versioning (a la x.y.z), but I'm also aware of the burden it will bring tothe workload of this project, so in the end I think we won't have many tags/version (and the vita is already in it EOL cycle), hence the idea of a automatic (daily/weekly/monthly) tagging system.

Well... that's just my pessimistic view 🎉

[yne]

As discussed on IRC:

The naming will be major.minor . I'll create a 0.1 tag (detail at the end of the post)

The major is bumped when there is a breaking change in the API, otherwise, the minor is bumped.

Breaking changes examples :

• NID renaming/deleting
• breaking changes in the headers (struct renaming/reordering)
• non backward change in the CLI (removing/renaming an option)

Non breaking changes examples:

• new NID/Library
• new Function/Enum/Struct declaration in headers
• new option in the CLI

To avoid Chrome-ish version, update could be grouped before release (at a speed of a couple of month per release)

Some developers would still need to use an older version of the SDK alongside of they current one (eg. if they want to build an old binary). This require isolations of the vita headers, vita libs, binaries, libs (libelf ...). This kind of isolation could be done with docker images but it's not the subject of this thread.

New release tagging would require a simple QA step (build and start a user+kernel app & user+kernel plugin)

** the v0.1 testing tag **

I'll create this training tag , so everybody can update they tools to fetch/handle tags (vdpm, jenkins ...).
If this tag generates issues (nightly failure,...), just delete it. And give us some details here about what went wrong.
Once everything is stable, we can tag to 1.0 and celebrate.

Edit : I updated the todolist (even if it say v1.0)

[LiEnby]

like when celeste corrected all the places certain functions acturally where in libarys but you guys threw it out because it broke compadibility lol

[yne]

From someone having to deal with Angular constant breaking changes, I couldn't agree more. 👍

• who decide release & manage new version

I've serious doubts that someone would be delighted to do this. Futhermore, human arbitrary naming may cause drama. So the only sane solution is to define a versioning rule that everyone would agree on.
For example, you suggested a major.minor naming which mean (if not manually incremented by a human) that we shall bump the major on every API breaking change, like #354 or #355.
I'm not a soothsayer but judging by the look of the accepted MR, we will catch up with Chrome version by the end of next year.
An other human-less alternative versioning could be year.month (a la Windows / Ubuntu), this way the increment could be done heartlessly by the CI.

• most cases we always used latest dev version like other platform sdks.

So maybe we should live with this behavior and carry it by explicit any API breaking changes in the doxygen, so after an SDK update, developers trying to google why the function disappeared will find the new name with an explanation "Was renamed from $oldname, see #987". This shall reduce the frustration while porting to the new version. But this also may encourage to keep using master instead of version. Making all the versioning efforts worthless.

[d3m3vilurr]

I'm not a soothsayer but judging by the look of the accepted MR, we will catch up with Chrome version by the end of next year.

lol. that cons parts is joke.

when I open the issue, I thought, we need method for handling NID changes and moving.
because it really following breaking changes.
so we cannot choose those approach whether that is right or not.

other repositories of vitasdk have same problem.
we cannot choose experimental changes for those repos.
for example, vitasdk/newlib#38, vitasdk/buildscripts#52 and vitasdk/vita-toolchain#119

if they are right or implemented useful feature, basically we cannot choose that.
so still we use old gcc and old newlib. (well.. it could be okay anyway)

stable means that the version get a guarantee of stability from the maintainers.
mastar can have same meaning. but most cases, it's not.
can you guarantee master is stable? I can't that.
so we need the tag.

version rule is one of important part of this issue, but we cannot use auto increment for that.
also if you have idea, just tell here.
or request conversation in IRC.

if you really think version managing is useless, you should read upgrade guide before googling.
release always needs that guide if that version has breaking changes.
also minor version update always needs backward compatibility and notify deprecated information if have it.

actually, #354 is minor issue. but you told it's broken changes. I think it's our system's problem.

[yne]

if you really think version managing is useless

Nope, never said that.
I said that tagging (not just the git tag part, but all the testing/checking that goes with it) is a very long, time consuming, and repetitive task, leading me to believe that not much people would enjoy to do it.
I've done Integration tests / Stability check one time for my job.. It took me and 2 other colleagues 3 weeks (full time). And during those 3 weeks I wish a dropped college and went pastry cook instead.
But maybe I'm wrong, and maybe someone will be happy to manually check the stability of the whole SDK ... each time... for the next 10 years... (I'm not joking, there are still now opened issues on the pspsdk).

can you guarantee master is stable? I can't that.
so we need the tag.

I would have said that we need more end-to-end tests.
The tag shall be only given if all those tests went successful.
If there is still a bug on a tagged release it mean that more tests need to be written :)

Okay, I'll try to be reachable on IRC

[d3m3vilurr]

well.. we just check the stability when we release new version(attach the tag), it just needs to check that sample can compile and works (for that we should need to change samples).

if some developers use the nightly of the dev line, it just have one means, they can encounter breaking changes in every time.
and we don't need to care about that. so we can delegate the responsibility to those developers.

yea we also need qa plan before release, but I'm not sure that needs really big time.
remain/opened issue doesn't have the meaning that isn't stable. it just have the meaning that version just have the known issue.

anyway if you join into freenode #vitasdk channel(or join the discord/matrix channel) please call me :)

[devnoname120]

Note that @gnuton has made a docker that has tagged releases. Useful for example for continous integration. https://hub.docker.com/r/gnuton/vitasdk-docker

[d3m3vilurr]

yeah... dockernize would be good idea. but it is system dependent method, and the managing of installed libraries would be one of mess point

[yne]

@devnoname120: yeah just like:
https://github.com/psvsdk/psvsdk
https://hub.docker.com/r/psvsdk/psvsdk

Now that Docker can be used by "the mass" (thanks to WSL2), maybe we should enforce docker as primary method because it offer a reproductible build environment => so no more "no we can't add folder support to vita-make-vpk because older toolchain will not understand it". And we could advance without being worried that older homebrew could break.

On the other hand, the developpers must declare what docker tag they hombrew is build on, so anybody could build them using the same image.

Edit: IMO using the timestamp (YYYYMMDD) as docker tag is good because it could be automatically build ed/tagged by travis and it will "snapshot" the lib+sdk+header of that day.

[gnuton]

Hi,
@yne I do not think using YYYYMMDD as a tag for docker images is a good idea. I see that just as a workaround for not having upstream releases. I do not even know if generating 100GB of data and 365 releases per year is okay for a free account in docker hub either..
In any case, I would really love to get release versioning, that would be the proper solution.