search

ps2homebrew / Open-PS2-Loader

Game and app loader for Sony PlayStation 2
https://ps2homebrew.github.io/Open-PS2-Loader/
Academic Free License v3.0
2.2k stars 277 forks source link

Create stable releases, starting with v1.0.0 #343

Closed rickgaiser closed 3 years ago

rickgaiser commented 3 years ago

I'm going to give this another try. What I would like to propose is the following:

opl_versioning2

I would like to tag the current version of OPL as "v1.0.0", this will be the new release. All development continues on the master branch towards making the next release: "v1.1.0".

From the "v1.0.0" tag I would like to start a stable branch, named "v1.0.z". On this branch only bugfixes from the master branch will be applied (no new features or changes to existing ones!). This will over time result in more and more stable releases: "v1.0.1", "v1.0.2", etc...

I would like to maintain the stable branches.

If there's no objections to doing it this way I would like to start making the changes and sending the PR's soon.

AKuHAK commented 3 years ago

Great! I am still alive to finally see 1.0 version of opl. Congratulations.

fjtrujy commented 3 years ago

Thanks @rickgaiser for all your huge effort to make this to work!

TnA-Plastic commented 3 years ago

While I do have the feeling that some small things might be "missing" at some points, I also think that OPL is MUCH more "mature" now compared to the last official stable release and the benefits of a new stable release would yield WAY more benefits than disadvantages!

tl;dr That's awesome and yes, please "go for it".

J013k commented 3 years ago

Theoretically we can also use 0.9.5 instead of 1.0.0. https://s3.postimg.cc/9dl7d0wpf/8d2ad9671de3.jpg Why not 0.9.4...

Because a lot of improvements have been done:

Although there are still some known bugs... that is why 1.0.0 does not suit me... But it is only my opinion, I am not a developer...

rickgaiser commented 3 years ago

Theoretically we can also use 0.9.5 instead of 1.0.0. Why not 0.9.4...

We could but that would not do justice to the number of changes that have been made. The versioning also has a meaning. In OPL it's:

VERSION = 0
SUBVERSION = 9
PATCHLEVEL = 3+

But the more commonly accepted versioning is: https://semver.org/ :

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

Increasing the version to 0.9.4 or 0.9.5 basically means we have fixed 1 or 2 bugs... So we should at least increase the MINOR/SUBVERSION. That would be "v0.10.0". But looking at the list of changes, I think this justifies at least 1 MAJOR/VERSION change.

Although there are still some known bugs... that is why 1.0.0 does not suit me...

This is what stops us from increasing the version every time. A bug free version in the master branch is never going to happen becouse new features/improvements are constantly added. But in time, "v1.0.z" could become stable. Not "v1.0.0", but perhaps "v1.0.5". Each bugfix added to the master branch can also be applied the the stable branch, and released as a new version.

Tupakaveli commented 3 years ago

My 2 cents is I agree with the v1.0.0 tag and it's a good starting point to do proper versioning.

@rickgaiser thank you for the work.

J013k commented 3 years ago

This is what stops us from increasing the version every time. A bug free version in the master branch is never going to happen becouse new features/improvements are constantly added. But in time, "v1.0.z" could become stable. Not "v1.0.0", but perhaps "v1.0.5". Each bugfix added to the master branch can also be applied the the stable branch, and released as a new version.

This is a pretty fair argument, so let's go. :)

BatRastard commented 3 years ago

Whoops! LMAO! Closed by mistake! :)

Meant to quote AKuHAK marveling at being alive long enough to see OPL 1.0 and mention that I'm just happy to not see a freaking social security check first! Sheeeeeit ... I'm closer to 50 that most of y'all are to death ... LOL!

My previous stance was to have a new "OPL 1.0" logo -- going so far as to brand it "OPL UNO! with the exclamation point upside down and bring back the original devs to do the compile & release honors. None of that shit's gonna happen so it's Rick, its all yours! 👍

rickgaiser commented 3 years ago

I've been playing with the CI and the version in the Makefile. My current master branch shows what I would like to push to ps2homebrew/master.

Please review carefully, I can still make changes to it:

If you look in the releases: https://github.com/rickgaiser/Open-PS2-Loader/releases

You'll see 1 release:

Then you'll see 1 "latest" release:

Once we have a new feature in OPL, like PADEMU ds5 support ;), we can release "v1.1.0", and continue our work with "v1.2.0-Beta". What do you think?

TnA-Plastic commented 3 years ago

I will start writing a news-thread in a few hours, as a preparation.

I am not quite sure, where I can get a complete list of changes. I know @ElPatas1 or @J013k probably have the completed list, but I am not certain how complete it is.

That's going to be a great surprise for the PS2-Scene! :)

J013k commented 3 years ago

[s]I think that no one has a simplified changelog...[s/] EDIT: I guess I was wrong. You can use this one as a start (however I made a few typos): https://github.com/ps2homebrew/Open-PS2-Loader/issues/343#issuecomment-752789072. Game fixes (Recent fixes tab): https://www.psx-place.com/threads/open-ps2-loader-game-bug-reports.19401/.

More info you can get from DETAILED_CHANGELOG: https://github.com/ps2homebrew/Open-PS2-Loader/releases/download/latest/OPNPS2LD.ZIP.

ElPatas1 commented 3 years ago

@J013k, i have been doing a simplified and recompiled Changelog for a long time since OPL 0.9.3, and that i updated several times on the Discord PS2 channel.

Here it is:

Changelog OPL v1.0.0

https://mega.nz/file/ZsxzlAoQ#1ZW1Z-UwrX30s3OOKneU_6I1_Y-nh0_-UMf6zXdEW90

Best regards.

rickgaiser commented 3 years ago

@ElPatas1 after the release is created, would you like edit the release text? The changelog that gets created automatically is not very userfriendly.

ElPatas1 commented 3 years ago

@rickgaiser, you mean the CHANGELOG file that is part of the repository files? this one?

https://github.com/ps2homebrew/Open-PS2-Loader/blob/master/CHANGELOG

Here i have it updated and completed , you can update it yourself by replacing the one that is there when you create the release, if it is done later it will create a new commit just for having made this change, i don't know when it is more convenient.

Here the complete updated CHANGELOG file:

https://mega.nz/file/IhxnSAIZ#5HtOOTSMU9TmXPb2poqw9LOefixeleq56FII-miVV_o

Best regards.

rickgaiser commented 3 years ago

No I mean the github release text: https://github.com/rickgaiser/Open-PS2-Loader/releases/tag/v1.0.0

Perhaps your complete changelog file can be put there also. With some additional formatting to make it look nice.

ElPatas1 commented 3 years ago

I see, this is so ugly.

In the link you provided the Edit button do not exist.

I guess after creating the release the Edit button will appear.

Yes, then i will edit it and do the best i can, i don't think it will allow me to use a format in that place to make the changelog beautiful, the edition is very simple there, it will have to be seen.

Anyway in all the previous releases do not exist this type of information on the releases page.

Best regards.

rickgaiser commented 3 years ago

As discussed on discord: perhaps it's a good idea to release a "release candidate" first. This would be a version everyone can test before "the big" v1.0.0 is released. So for instance:

Keep in mind that this happens on the master tree, so the time period between starting rc's and releasing a new version is limited. This is becouse during this phase, only bug fixes are allowed. New features will have to wait untill v1.0.0 is released.

Also keep in mind that it's ok for v1.0.0 to still have some bugs. They can always be fixed in v1.0.1, v1.0.2, etc...

I can push the updated CI code and the v1.0.0-rc1 tag tomorrow.

edit: more examples added to make more clear what will happen after v1.0.0

TnA-Plastic commented 3 years ago

Yes, that's a good idea! 👍

It's actually an obvious solution and except for you, we all failed to think of it, haha!

@J013k, @ElPatas1 and I (+ possibly others) can probably sleep way better with this way/solution.

I still can't believe it. We are really on our way, to get 1.0.0 out! Awesome stuff!

@ElPatas1 Btw.: One thing is missing from the changelog... I know it isn't really related to the changes in the app, but it is important to mention IMO.

The build-bot which allows users to download the newest builds just in time, right when the changes are/were merged! Why? Well... A lot of users use an OPL-fork which claims to be the newest, best, etc. Version... The build-bot possibly will get some more people off of that fork, back to the newest, most stable original builds!

KrahJohlito commented 3 years ago

This new versioning sounds good to me too, stable release has been a long time coming.. and as I've said a few times to others.. if people just waited for their software to be 100% bug free before releasing...there would only ever be one version and versioning would be pointless.... I'll be glad to see a new stable released!! :-)

rickgaiser commented 3 years ago

Here's the first release candidate for OPL v1.0.0: https://github.com/ps2homebrew/Open-PS2-Loader/releases/tag/v1.0.0-rc1

Please test it and report any issues you find.

ElPatas1 commented 3 years ago

@ElPatas1 Btw.: One thing is missing from the changelog... I know it isn't really related to the changes in the app, but it is important to mention IMO.

The build-bot which allows users to download the newest builds just in time, right when the changes are/were merged! Why? Well... A lot of users use an OPL-fork which claims to be the newest, best, etc. Version... The build-bot possibly will get some more people off of that fork, back to the newest, most stable original builds!

@TnA-Plastic, i think that mentioning the build-bot is more appropriate to do it in the README file and not in the CHANGELOG file, but if the rest of the developers agree with you feel free to add it yourself, above i have put the download of the complete CHANGELOG.

Best regards.

J013k commented 3 years ago

Please test it and report any issues you find.

What do think about adding somewhere "known bugs\issues"? GUI:

In game:

Still problematic games:

rickgaiser commented 3 years ago

The build-bot which allows users to download the newest builds just in time, right when the changes are/were merged!

i think that mentioning the build-bot is more appropriate to do it in the README file and not in the CHANGELOG file

I agree with @ElPatas1 Mentioning in the README where OPL can be downloaded from, and what versions there are should be sufficient.

What do think about adding somewhere "known bugs\issues"?

Good idea. In theory ALL mentioned issues should have a github issue associated with it. And ALL github issues should be mentioned as a know issue, right? Perhaps CI can generate the list, but that's a topic for another day. I'll make an issue about the file sizes.

TnA-Plastic commented 3 years ago

Alright!

I mention(ed) the Build bot in the "Additional notes"-Tab on the upcoming news-thread.

I will add another tab "Known issues" to it later.

TnA-Plastic commented 3 years ago

A special shout-out to the initial creators of the Project, @jimmikaelkael and @ifcaro!

I'm just making sure, that you see that your "old" project came to this stage.

If one of you is still around and knows when the first USBLD was released, please tell us!

I added the things I wrote about in my previous post (tab: "Known issues" and the "Additional notes"), to the WIP-News-post.

rickgaiser commented 3 years ago

I've seen no new issues, so this release seems stable enough to me.

Should I release v1.0.0 today? @ElPatas1 you can edit the github release text after it's been created? @TnA-Plastic you can inform people on forum/discord?

Then immediately after I will update the version to v1.1.0-Beta so we can start adding new features again (like #347)?

KrahJohlito commented 3 years ago

@rickgaiser you probably already know but just in case you haven’t seen it before, don’t forget about this for the release. 👍

rickgaiser commented 3 years ago

No I didn't know about that, and I'm not sure what to do about it...

Since commit https://github.com/ps2homebrew/Open-PS2-Loader/commit/f800e99ea8765c0768fd87096b15f7ed4681ea91 we're no longer using the 'CFG' folder, but instead we're using the 'CFG-DEV' folder? So for the past 5 years, we've all been using CFG-DEV. Including all active users.

Possible solutions, in order of my preference:

  1. Start using 'CFG', remove 'CFG-DEV' and OPL_IS_DEV_BUILD. We must all copy our configs from 'CFG-DEV' to 'CFG' once.

  2. Keep using 'CFG-DEV' forever, remove 'CFG' and OPL_IS_DEV_BUILD. It's the most simple and compatible option, but not the nicest.

  3. Make the 'CFG' folder location configurable. Then the user/developer can set it to whatever he likes. More work for a useless feature, but flexible.

  4. Configure OPL_IS_DEV_BUILD automatically, based on git tag. But this mean what we're all testing is not the same as what we're releasing.

I think the CFG system is stable enough to remove this weird switch static between 2 folders. Developers can change the code/folders to their needs anytime if needed, but I don't think there's much need to do this.

Should I create an issue and PR for option '1' ?

Tupakaveli commented 3 years ago

That flag was used for downloading configs from the OPL-CL site.

rickgaiser commented 3 years ago

That flag was used for downloading configs from the OPL-CL site.

The flag is used to define the one-and-only CFG folder location. Both downloaded and manually configured. If I look in my own OPL folder I only have a 'CFG-DEV' folder, no 'CFG' folder. And all my manual configs are in that folder. @brainstream this topic might be interesting to you as well.

Tupakaveli commented 3 years ago

That flag was used for downloading configs from the OPL-CL site.

The flag is used to define the one-and-only CFG folder location. Both downloaded and manually configured. If I look in my own OPL folder I only have a 'CFG-DEV' folder, no 'CFG' folder. And all my manual configs are in that folder. @brainstream this topic might be interesting to you as well.

Yes. The config folder location for downloading configs from OPL-CL.

KrahJohlito commented 3 years ago

I’m pretty sure OPL-CL does use it as well as the cfgVersion variable in the cfgs themselves... which got all messed up in OPLM, cfgVersion is meant to only ever by 0 or 1 depending on whether it’s a beta or not.. same goes for OPL_IS_DEV_BUILD

edit: IcySon55 hosts OPL-CL and set it all up with sp193 afaik, he is also on the discord so he would have all the correct info in case anything I’ve said is incorrect.

fjtrujy commented 3 years ago

@rickgaiser there is an easy way to make this flag dynamic. You can use same approach that I did in ps2toolchain and ps2dev if the git repository in this moment is in a "tag", which mean is a "PRODUCTION RELEASE", then you add a flag in the compilation as -DOPL_IS_DEV_BUILD=0 otherwise -DOPL_IS_DEV_BUILD=1

I can help you with this. The requirement is just to tag the version.

Just to have in mind guys, the idea for a release, is to DON'T CHANGE ANYTHING in the code in order to do a release, in my opinion, the only, only requirement, is to tag it.

Thanks

rickgaiser commented 3 years ago

The flag is used 2 times:

It changes the CFG folder location: https://github.com/ps2homebrew/Open-PS2-Loader/blob/daa05c04c7298b890adaec2b20887be3c22a6d7e/include/opl.h#L46-L50

And it sends an extra parameter (dev=1) to OPL-CL: https://github.com/ps2homebrew/Open-PS2-Loader/blob/41f7cf0b782628ef237527598225a2f628a376dd/include/compatupd.h#L8-L12

But I don't know what the website does with this extra parameter?

fjtrujy commented 3 years ago

Then I think that we should remove this flag at all

IcySon55 commented 3 years ago

The dev flag that is sent to my server determines whether or not compatibility configs linked to an in development launcher version are included in the sync operation or not.

If you want to remove the flag, I'll probably just hardcode the interaction of sync.ashx so that dev is always 1, thus the most recent configs are always pushed.

Completely removing the flag on my end is more work than I can do atm. Optioinally I can set all launchers to "not in dev" status.

But it seems to me that the proper fix is to remove the launcher list entirely and keep only a single set of configs? (This assumes no legacy version users)

TnA-Plastic commented 3 years ago

I think this can be replaced by a string in the game-settings-file, which names the last compatible version.

Hence I think the flag could be removed for now.

@rickgaiser Yes, I will mention it to "everyone" on Discord and have a WIP-news-article.

It's lacking the final full and the "shortened" changelog for now.

rickgaiser commented 3 years ago

So if I understand this correct:

So basically it's a version number, not indicating a dev/release build.

I think the simplest and most safe thing to do then is hardcode dev=1 in OPL, like it's been the past 5 years. Then both new and legacy users are happy, and @IcySon55 doesn't have to change the server.

IcySon55 commented 3 years ago

Actually no, it's not a version number.

OPL-CL keeps a list of launcher versions. Each one can be set to one of three states: 1 (Obsolete) 2 (Stable) 3 (Development)

image When dev=0, configs created for launchers that are State=3 are ignored.

I can simply change the launchers all to Stable and then dev becomes meaningless.

As it stands the system can store multiple configs, per Launcher version, per Device, per Media, etc. and sync sorts them by Device first (based on requested device=%d) and then most recent launcher version.

rickgaiser commented 3 years ago

I can simply change the launchers all to Stable and then dev becomes meaningless.

If you think that's the best solution, agreed. And then we can remove dev=1 from the http request?

IcySon55 commented 3 years ago

Yeah, removing that would be fine. I'ill be updating all new versions to Stable.

Actually based on the list above, are there versions that I'm missing?

KrahJohlito commented 3 years ago

@TnA-Plastic can you just make a note in the release thread about the switch from CFG-DEV to CFG just in case some users are unaware.. even the development builds will be using CFG from now on.

TnA-Plastic commented 3 years ago

THX for the hint. Yes, I will add it! 👍

Edit: Done!

HowlingWolfHWC commented 3 years ago

v1.0.0 should be ready to go. Then we could do OPL v2.0.0 when we add the UFOs from Area 51....

rickgaiser commented 3 years ago

Congratulations everyone, v1.0.0 is here: https://github.com/ps2homebrew/Open-PS2-Loader/releases/tag/v1.0.0

gingerbeardman commented 3 years ago

Congrats!

rickgaiser commented 3 years ago

@ElPatas1 can you create a proper text with the release? It's now only mentioning the 2 commits between rc1 and the release. https://github.com/ps2homebrew/Open-PS2-Loader/releases/tag/v1.0.0 You should have an "edit release" button.

ElPatas1 commented 3 years ago

@rickgaiser,

@ElPatas1 can you create a proper text with the release? It's now only mentioning the 2 commits between rc1 and the release. https://github.com/ps2homebrew/Open-PS2-Loader/releases/tag/v1.0.0 You should have an "edit release" button.

Done.

Best regards.