Hi Animesh,

The following lines are my idea.

The version number could be in a popular format
major.minor.patch

1. The master branch keeps the major & minor SNAPSHOT versions. (e.g. 
1.0.0-SNAPSHOT, 1.1.0-SNAPSHOT, 2.0.0-SNAPSHOT)
2. The release branch (e.g. branch-1.0) keeps the patched SNAPSHOT versions. 
(e.g. 1.0.1-SNAPSHOT, 1.1.2-SNAPSHOT)
3. Use git tags (e.g. v1.0.3) to cut a release. Once released, the SNAPSHOT 
suffix needs to be removed. And then, the release branch moves on to the next 
patched SNAPSHOT version.

Maybe my idea is the same as yours? 😁

> On 31 Jan 2018, at 02:33, Animesh Trivedi <animesh.triv...@gmail.com> wrote:
> 
> Hi Dawn,
> 
> what specifically do you have in mind? I agree that once we start to have
> periodic releases (hopefully soon) we will tag corresponding git branch
> with the version number. Since, there is no release, all the code is in the
> master branch.
> 
> If you tell us what do you have in mind, we can include that structure :)
> 
> Thanks,
> --
> Animesh
> 
> On Tue, Jan 30, 2018 at 3:36 PM, Dawn Shepherd <dawnshepherd0...@icloud.com>
> wrote:
> 
>> Hi all,
>>        I am not in the Crail team and I have a suggestion. Perhaps the
>> Crail project could use Spark's branching model? I think it is very simple
>> and practical

Reply via email to