Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version naming #53

Closed
GOLASOOO opened this issue Feb 20, 2024 · 9 comments
Closed

Version naming #53

GOLASOOO opened this issue Feb 20, 2024 · 9 comments
Labels
discussion 🗪 Something needs some discussion

Comments

@GOLASOOO
Copy link
Contributor

How should we name the new version for the next delivery?
@jjgancfer and me were discussing about this previously. He thought about 1.0.0 because the new version is not compatible to the previous one. However, it seems weird for me to start at 1 as the project is the first functional prototype.

@jjgancfer
Copy link
Contributor

As I told @uo283928, last Monday's release was 0.0.3, which does not contain any of the code we have worked on the last weeks. I thought that since we are changing a lot of the original code for the next release, we should use 1.0.0 because it will not likely be backwards-compatible (according to semantic versioning, it will be a MAJOR version).

@UO283615
Copy link
Contributor

I agree with Jorge that semantically this should be named 1.0.0 although for symbolic reasons I would like the last deliverable to be the 1.0.0

@gony02
Copy link
Contributor

gony02 commented Feb 22, 2024

I agree with @jjgancfer that we should start with version 1.0.0. After some weeks, as we approach the final version of the project, we could name it, for example, 2.0.0 RC 1 (RC stands for Release Candidate and 2.0.0 is an example). At the end, the final version would be 2.0.0 (this is an example).

@jjgancfer
Copy link
Contributor

I agree with Jorge that semantically this should be named 1.0.0 although for symbolic reasons I would like the last deliverable to be the 1.0.0

If I remember correctly, last year's last version (according to versioning system used back then) was 1.1.x. Having 1.0 be the version for the last deliverable would be great, but may not be possible as we have many others before.

@Toto-hitori
Copy link
Contributor

The deliverable with the 1.0.0 denomination should be the first one that includes the mandatory requirements for the project. After that the naming will probably only increase like 1.X.X since we probably will not have any breaking changes that will force us to name a version after 2.0.0. Hotfixes might also be needed so the 1.0.X thing will be used as well.

@Toto-hitori
Copy link
Contributor

For more info about version naming please check the following:
https://semver.org/

@UO283615
Copy link
Contributor

So we should go with 1.0.x for this deliverable, right?

@UO283615 UO283615 added this to the Second delivery milestone Feb 26, 2024
@jjgancfer
Copy link
Contributor

I don't think so. @Toto-hitori intends to make a test deployment either today or tomorrow, so that would probably be labeled 1.0.0 already since a lot of the functions we want to include will be present and then next week would be 1.1.0, as only small changes will take place.

@Toto-hitori
Copy link
Contributor

The deployment I plan to do tomorrow, although including SOME of the features planned for the first release, does still not include all of the features needed for the MVP, only authentication mainly. Thus, it should still follow the 0.X.X format until we deploy what includes the question generation, which will be then labeled 1.0.0. Finally the version that includes the game logic could include the 2.X.X since it will include a breaking change and so on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion 🗪 Something needs some discussion
Projects
None yet
Development

No branches or pull requests

7 participants