[Bf-cycles] Cycles releases
Thomas Dinges
blender at dingto.org
Thu Mar 31 01:24:19 CEST 2016
I went with version 1.7.0 now, and commited some code to the standalone
repo.
https://developer.blender.org/rCcd5d3edb9fa4050dc0d8186b649eda815bd54f75
Will improve code and add info to UI later. This can still change and we
don't have to rush a tag anyway.
Am 30.03.2016 um 23:05 schrieb Brecht Van Lommel:
> +1 for release branches, and doing development on master.
>
> I don't really care about the version number much at this point.
> Eventually it would be nice to use semantic versioning, with the
> release number indicating API backwards compatibility. But we are not
> ready for that yet, first we need a better defined public API for
> that. Starting at 1.whatever is fine with me.
>
> On Tue, Mar 29, 2016 at 10:43 AM, Nathan Letwory <nathan at mcneel.com> wrote:
>> Hey all,
>>
>> I'm happy to notice that this is being brought up. From the posted
>> suggestions I'd also go for using release branches. I don't have a
>> strong opinion about versioning scheme. The main point is to have one.
>>
>> Up until now using current development has been fine, but once
>> integrations (Rhino v6 and Grasshopper - we're *hoping* to get that out
>> during summer) are out there with the public it'd be good to have a
>> clear release and versioning system in place, especially for continued
>> development after that.
>>
>> If there is any syncing work that could be divided amongst active Cycles
>> repository users and devs then that might help with getting a good
>> handle on the progress.
>>
>> I can at least handle part of the syncing etc., but I'd prefer not to be
>> the only one here ;)
>>
>> /Nathan
>>
>> On 3/29/2016 10:35 AM, Sergey Sharybin wrote:
>>> 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
>>>
>>
>> --
>> Nathan Letwory
>>
>>
>> _______________________________________________
>> 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
> https://lists.blender.org/mailman/listinfo/bf-cycles
More information about the Bf-cycles
mailing list