On Tue, 11 Dec 2012 20:15:28 +0100 Togan Muftuoglu <[email protected]> wrote:
> On 12/11/2012 07:48 PM, parafin wrote: > > On Tue, 11 Dec 2012 19:43:55 +0100 > > Togan Muftuoglu <[email protected]> wrote: > > > >> On 12/11/2012 07:38 PM, parafin wrote: > >>> On Tue, 11 Dec 2012 19:19:42 +0100 > >>>> Maybe a better solution, just a thought, is to follow a structure as > >>>> outlined in <http://nvie.com/posts/a-successful-git-branching-model/> > >>>> > >>>> This approch could help us solve the versioning issues for us,the > >>>> nightly package builders > >>> > >>> There's nothing in there about patch releases so what's exactly you're > >>> proposing? Just don't do them? Or always release git master? That won't > >>> work for us. > >>> > >> > >> Look at the release and hotfix branch approch > > > > I'm looking at them. Their approach is different from ours, changing > > development process just because of version numbering issues sounds > > stupid, I don't see any need for this. > > Well then to be constructive why not propose a model that will work for > those of us who do provide a different version numbering just like when > you build from the git your darktable version is not 1.2.3.4 anymore but > it has to do something with the git shas. > > If the current model was answering the needs we wouldn't be having this > topic Heh, how exactly your link was constructive regarding to this issue? For example hotfix releases in their process will result in the same discrepancy in "git describe" output as we have now. 2 variants have already been proposed - either 1.1.9999 or 1.3 plus suffix with number of commits since last release and optional truncated sha1sum of current commit. With current git master state this could be one of this: 1.1.9999+112~g888848f 1.1.9999.112 1.3+112~g888848f 1.3.112 1.3.0.112 To achieve this we should do the following when git master approaches next major release time (and keep minor releases model the same as now): git tag release-1.5 or release-1.2.9999 git branch darktable-1.2.x (or 1.4.x) do some commit in that branch and tag it as release-1.2 (or 1.4) And be careful with merging branches after that (only do cherry-picking to darktable-1.*.x branch). For now we can similarly tag any commit in master after last merge into darktable-1.1.x. > > Togan > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > darktable-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/darktable-devel ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
