[Bf-cycles] Cycles releases
Thomas Dinges
blender at dingto.org
Tue Mar 29 10:32:26 CEST 2016
Hey Sergey,
yes I can help coordinating that, fine with it. :)
As for the releases, of course this depends on available manpower and
demand from external parties. We will see about the schedule.
As for the versioning scheme, I would rather go with 1.x, 2.x etc, from
a pure marketing point of view. Don't underestimate the power of this.
:P Anyway, I can live with all possibilities here.
Probably Brecht should have the final word on this, he is the creator
after all! :)
Best regards,
Thomas
Am 29.03.2016 um 09:35 schrieb Sergey Sharybin:
> 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
> <mailto: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 <mailto: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 list
>> Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org <mailto:Bf-cycles at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
>
>
> --
> 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/20160329/f0298051/attachment.htm
More information about the Bf-cycles
mailing list