That said, I would like to propose a discussion about create a new standard for versions and releases. So I wrote an draft. It is just a suggestion, I would like to hear from you if it is worth. If yes, after the contributions we can compile a entry in the wiki and use it like a simple guide.Actually I have more doubts about revisions, branches, releases, etc... I will start a new thread so we can discuss it.
-Filipe
I totally agree with you, it's a bit messy right now. However, I'd like to merge everything back in the trunk since the code is pretty solid now...
-Uze
The version number rules:
Simple solution using 2 fields:
0.0 (major and minor)
The "major" changes always with big changes or when the API changes breaking compatibility.
The "minor" changes for small implementations: best performance, bug fixes, new tools, new games, etc
The releases rules:
The releases are made when a group of implementations are ready in the trunk. They bump the version using the version rules.
A release is made by:
* Creating a new "tag" in SVN
* Creating a featured package
Note: There is no current standard on the package names: devkernel010310.zip, kernel.zip, uzebox-beta5-rev109.zip. Since the Uzebox is more than the kernel, the best name is the project's name followed by the version number. If a version is not closed but for some reason we want create a public package, we can use something like "dev" or "beta" followed by the SVN revision number. This way all the names are easy and anyone knows exactly where to find the code in the repository.
Examples:
uzebox-2_0.zip
uzebox-2_1.zip
uzebox-dev-rev118.zip
uzebox-3_0.zip
Trunk and branches rules:
Trunk contains the latest implementations done! It is supposed to be in good health (aka not broken ).
New implementations can be done using branches. After to move the code to trunk, remove the branch.
Sub-projects:
Uzebox is composed by hardware, kernel, demos, tools, resource files. We have a release version, but how about the version of each sub-project ?
I'm not sure about this, keep using a global version is more simple and easy, but is weird for example if between versions 2.2 and 2.3 nothing changes for the kernel, but the schematic has changes. We have kernel 2.2 that is equal to kernel 2.3.
But it is ok if we think that we don't have kernel the kernel vesion xxx but we have the kernel from the Uzebox version 2.3 and looking the Changelog between 2.2 and 2.3 we know the kernel didn't change.
My vote is keep a global version, it is more simple. We can create a simple file like version.mk and include it in all the Makefiles.
The current status:
Trunk - Based on the README, it is 2.0-beta3
Branch/rev_beta4 - 2.0-Beta4
Branch/rev_beta5 - 2.0-Beta5
Sugestion,
Create a tag from trunk: 2.0.beta3
Commit branch beta4 to trunk and create a tag: 2.0.beta4
Commit branch beta5 to trunk and create a tag: 2.0.beta5
The next will be 2.1
Other details:
*Remove the version from the README file name, otherwise the file must be copied and deleted in the SVN each time.
*The packages are being created using the checkout svn command. This is not good because it contains the ".svn" directories. Use the command "svn export", it works like "checkout" but without the ".svn" directories.
-Filipe Rinaldi.