[Bf-cycles] Cycles releases

Sergey Sharybin sergey.vfx at gmail.com
Mon Mar 28 19:10:41 CEST 2016


Hey,

= Preamble =

Some time ago we had IRC discussion with Nathan about tagging Cycles's
repository once Blender gets a new release. At that time as i understood
main reasoning was to make it real clear which revisions of Cycles
repository are considered stable and which could cause you a troubles due
to WIP features.

= Issues =

While it's all legit idea and something we should definitely have, it's a
bit more tricky in implementation since the following reasons:

1. Code freeze periods
2. Need tag name convention

First issue is coming from the fact that in Blender we're doing a release
branch at the RC time. There's no new features committed to that branch
(only bug fixes), but non-intrusive work continues on master branch after
Blender RC1 is out.

In Cycles we've got a single branch, which with current situation will mean
we wouldn't be able to synchronize any of the new code from Blender to
Cycles during the RC period of Blender (which could be 3-4 weeks easily).
That's something to be avoid in fact.

Second issue is more a convention. We would just need to agree on version
system. I just don't feel like using Blender's versions for Cycles -- while
releases can totally be synchronized, to me it makes more sense to have own
versions for Cycles.

= Ideas =

Looking on all that here are couple of ideas how we can move forward.

== New branch: devel ==

The idea is simple: we move all on-going development in Cycles's standalone
repository to a new branch called `devel`. Technically it'll mean we'll
synchronize commits from Blender NOT to master but to devel branch.

Once Blender is released we'll fast-forward devel branch to master.

As simple as that. That would solve requirement of distinguishing stable
Cycles from ongoing development one. Additionally, we'll be able to tag
master branch with annotated release tags. Read about that in next ideas.

== Have release branches ==

Other idea is to follow Blender's release process and keep all development
happening in Cycles standalone in the master branch and once Blender get's
RC branch we create same thing in Cycles. All crucial bugfixes will be
cherry-picked to that branch and when blender releases we'll tag the branch
in standalone repository and delete the branch (so we'll leave with just
tags).

== Tagging / versions ==

Here i propose to consider first tag 1.0, and next releases will be 1.1,
1.2 ... and so on, for until we do some major re-consideration in Cycles
(going bi-dir?) which would start 2.0 version.

I personal opinion that'd be natural for external users / developers of
Cycles.

= Comments? +

Now, i'm wondering what other both Cycles core developers and external
developers who integrates Cycles in other software think of how we should
process. Maybe i'm all wrong, thinking too much or maybe you guys will like
one of the ideas here.

Let's have a bit of communication/discussion here before changing the way
we operate with standalone Cycles repo!

P.S. Sorry for the lengthy mail..

-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160328/dadc70a3/attachment.htm 


More information about the Bf-cycles mailing list