[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