Release Management/Repo structure with 3.0
Contents |
Introduction
With the introduction of our new major version there raised the necessity to re designing the repo structure to adjust the new version and make the older one in sync with the new ones.
And this wiki is a formal announcement of the same as the proposed repo structure has already been shared in the mailing list to understand it's pros and cons.
Older Structure.
Our old repositories are quite efficient in accomplishing what they have been meant for and the same has been kept in mind while creating the new proposal.
Old repositories were like this:
- For Openbravo 2.50 all the repositories were under erp/devel.
- erp/devel/pi
- erp/devel/main
- erp/devel/api-checks
- erp/devel/dbsm-main
- erp/devel/try
- And for older releases every thing was under erp/stable
- erp/stable/2.3x
- erp/stable/2.40
- erp/stable/dbsm-2.3x
- erp/stable/dbsm-2.40
- Modules for 2.50 were under erp/mods (as modularity started with version 2.50)
- erp/mods
- erp/pmods
New One.
In this new one we have tried to make changes in such a way that the developers have to face the minimal changes in their day to day work. Now lets see one by one where do we have what and also what the developers have to change in their local clones
New repositories will be like this:
- Repositories for core 3.0 will be under erp/devel and more over we will use same main, pi, api-checks and try etc for it.
- erp/devel/pi
- erp/devel/main
- erp/devel/api-checks
- erp/devel/dbsm-main (common for both 2.50 and 3.0)
- erp/devel/try
- Repositories for core 2.50
- erp/stable/2.50
- erp/stable/try-2.50
- erp/stable/api-checks-2.50
- erp/devel/dbsm-main (common for both 2.50 and 3.0)
- Here comes the twist, the module repositories, as this is the first time we will have two major version supporting Modularity. And believe me it wasn't easy to take decision on this.
- erp/mods (common for both 2.50 and 3.0)
- erp/pmods (common for both 2.50 and 3.0)
Now the question will be how as it will have different version numbers in the same modules and also different fixes etc. So the answer to that is Named Branching.
What are named branches? To understand further one need to get the answer of this question. The answer to this in simple words is:
- Named branch is like having names for the heads in one repository (I think we all are familiar with heads).
To understand more about named branches please go though this.
So this is the main idea:
- The modules will remain in the same path where they are right now.
- The modules which need different changes or version numbers for 2.50 and 3.0 will have a named branch in the same repo. Which would mean:
- Giving an ease in cloning, as we don't have to clone two different repositories for the same module.
- To change from one repo to another will be one command away (hg up <branch name>).
And for special cases where modules pass from public to private or vice versa a real clone will be present in mods and pmods.
Example: erp/pmods/module (for 2.50) same is public for 3.0. Then can be handled like this erp/pmods/module (for 2.50) and erp/mods/module (for 3.0)
To explain the Named Branch scenario we have created a example repo. Please feel free to clone this repository if you wish to have hands on experience of the same.
These commands will help you:
- hg clone repo (this will give you clone with existing heads)
- hg clone -r core-2.50 repo (this will give you clone with only one branch core-2.50 in this case)
- hg pull -u (this will get you all the changes but you will remain in your working branch)
- hg up default (this will take you to the default branch which will be the latest Major version, 3.0 in our case)
- hg up core-2.50 (this will take to the core-2.50 branch)
Future
RM has also planned to give a training session to developers to get comfortable with this new repository structure and branching feature.