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 <[email protected]> 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 <[email protected]> > 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
