-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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). |
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 |
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). |
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. |
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. |
For more info about version naming please check the following: |
So we should go with 1.0.x for this deliverable, right? |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: