[Bf-cycles] Cycles releases

Tue Mar 29 09:35:36 CEST 2016

Hey,

@Thomas,

> Why wait for Blender to do a RC / Release, if we feel that the Cycles
side is stable already and justifies a new release?

Because all active Cycles developers are Blender guys and having extra
release to worry about (test, tag etc) inbetween of Blender's release is
kinda extra stress.

I'm not saying we can't do more releases than Blender, but currently we
don't have enough man power to properly cover that and making releases in
sync with Blender is just easier.

We can release more often later anyway.

> I would basically go with your suggestion of "Have release branches"

Same preference here actually.

> 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.

Yes, exactly. Or do a corrective releases inbetween. Or whatever. But
exactly "if we feel like it". As said before, having releases in sync is
just gonna be easier for the time being.

Once we'll figure out what exact way we'll want to go in this topic, would
you volunteer to help coordinating the work in standalone repo? ;)

@Mohamed,

> I would suggest developing Cycles alone with its own branches, and
merging this into Blender.

We don't have manpower for that and as mentioned above: majority of Cycles
contributors are heavily working on Blender anyway. Moving development
outside of Blender will just cause extra overhead for movie Blender itself
forward. For until there'll be stronger community around Cycles's master
branch i wouldn't really accept a model where Blender developers would need
to go into a hassle of developing something externally and then re-merge
the feature.

---

As for version: wouldn't really call it 0.1 increments, more like second
octet increments? Meaning, we go from 1.9 to 1.10 (instead of 2.0) unless
we made some really major refactor?

Where to start counting i don't really care that much, just personal
opinion that starting release of 1.7 is kinda marketing, but i can leave
with that.

On Mon, Mar 28, 2016 at 10:42 PM, Mohamed Sakr <3dsakr at gmail.com> wrote:

> Hi,
>
> a great topic.
> I would suggest developing Cycles alone with its own branches, and merging
> this into Blender.
> this will help in the future to Cycles Standalone, also porting it will be
> steady as Cycles will be the main pivot, at moment Blender is the main
> pivot.
> about versions, as DingTo said: 0.1 per Blender release sounds reasonable
> "assuming blender goes 10 releases every about 20 months (if I'm not
> wrong), this makes a good version step".
> version 1.0 looks young too, Cycles is production ready from long ago,
> though it got many parts that needs pushing, but the stable parts are
> already proven for production.
>
> cheers,
> Mohamed Sakr
>
> On Mon, Mar 28, 2016 at 10:29 PM, Thomas Dinges <blender at dingto.org>
> wrote:
>
>> 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 listBf-cycles at blender.orghttp://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>

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