[Bf-cycles] Cycles releases

Thomas Dinges blender at dingto.org
Mon Mar 28 22:29:23 CEST 2016


Hi,
that is an interesting topic.

My opinion here is, that we should have our own independent release 
schedule and version scheme for Cycles.
I might be wrong, but it already happened, that we didn't really add new 
stuff to Cycles for a bit and focused on other Blender related things. 
Why wait for Blender to do a RC / Release, if we feel that the Cycles 
side is stable already and justifies a new release?

I would basically go with your suggestion of "Have release branches" but 
stay independent of Blender here. In other words, we can create a branch 
at the same time Blender or do it in between at any other time, if we 
feel like it.

As for the versioning scheme, I always imagined it like taking a 0.1 
step per Blender release.
Blender 2.61 = Cycles 0.1
Blender 2.71 = Cycles 1.1
Blender 2.77 = Cycles 1.7

Anyway I would be fine either way, whether the first Cycles release will 
be 1.0 or e.g. 1.7, even though I think that 1.0 sounds a bit too young, 
the engine is certainly beyond that. :)

Best regards,
Thomas


Am 28.03.2016 um 19:10 schrieb Sergey Sharybin:
> 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
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160328/03b9ea43/attachment.htm 


More information about the Bf-cycles mailing list