Hi,
it sounds good to me.
The branching is a bit special compared to what I usually do, but I
understand the points (I have active branches where I can do release,
it's easier and it doesn't require merge).
I agree for the versioning.
Regards
JB
On 2014-11-12 01:14, amareshwarisr . wrote:
Hello all,
Here is current strategy we are following for branching and versioning
in
Lens. If people are fine with the same in apache repo also, I'm
planning to
push both master and develop branches to the repo.
* Branching
Lens has two main branches - <master> and <develop>. All the day to
day
development happens on <develop> branch. <master> branch is used to
make
releases. When develop branch is ready for release (all issues marked
for
release are fixed and all tests passing), develop will merged to master
and
release will be triggered from master. Once the release is done master
will
be merged into develop for version number upgrade.
If a critical release (not pulling code from develop) needs to be
made, a
new branch will be created with release number, by checking out master.
And
changes will be put on the branch. Once the branch is ready they will
merged to master and released. The changes should be merged into
develop
from master once the release is made and resolving conflicts in develop
if
any.
There can feature branches created, if feature is not actively
developed
in develop branch directly.
Having two main branches makes all release tags to be created on
master
branch and removes the pile up old and stale branches, which are
created by
one for each release. And Merging of issues done by critical patch
release
is already taken care.
* Versioning
Lens follows three number versioning which is major.minor.revision.
If
the current release is 1.1.0, the next usual development release will
be
1.2.0. If there needs to be separate release on released version and
not
from development branch (usually critical patch release), it will be
1.1.1.
If the next release is not api compatible with previous release, then
the
major version needs to be incremented, then it would become 2.0.0. This
way
all 1.x.x releases will be compatible with one another. And
incompatibility
is clearly communicated to users through major version number change.
Let me know your thoughts
Thanks
Amareshwari
