<div dir="ltr">Thomas,<div><br></div><div>Cool! Did some tweaks tho, so compilation wouldn't fail.</div><div><br></div><div>Will create real 1.7.0 tag later today (so you can grab exact Cycles code which we shipped in Blender 2.77).</div><div><br></div><div>And eventually we can go ahead and tag all previous releases actually.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 1:24 AM, Thomas Dinges <span dir="ltr"><<a href="mailto:blender@dingto.org" target="_blank">blender@dingto.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I went with version 1.7.0 now, and commited some code to the standalone<br>
repo.<br>
<a href="https://developer.blender.org/rCcd5d3edb9fa4050dc0d8186b649eda815bd54f75" rel="noreferrer" target="_blank">https://developer.blender.org/rCcd5d3edb9fa4050dc0d8186b649eda815bd54f75</a><br>
<br>
Will improve code and add info to UI later. This can still change and we<br>
don't have to rush a tag anyway.<br>
<div class="HOEnZb"><div class="h5"><br>
Am 30.03.2016 um 23:05 schrieb Brecht Van Lommel:<br>
> +1 for release branches, and doing development on master.<br>
><br>
> I don't really care about the version number much at this point.<br>
> Eventually it would be nice to use semantic versioning, with the<br>
> release number indicating API backwards compatibility. But we are not<br>
> ready for that yet, first we need a better defined public API for<br>
> that. Starting at 1.whatever is fine with me.<br>
><br>
> On Tue, Mar 29, 2016 at 10:43 AM, Nathan Letwory <<a href="mailto:nathan@mcneel.com">nathan@mcneel.com</a>> wrote:<br>
>> Hey all,<br>
>><br>
>> I'm happy to notice that this is being brought up. From the posted<br>
>> suggestions I'd also go for using release branches. I don't have a<br>
>> strong opinion about versioning scheme. The main point is to have one.<br>
>><br>
>> Up until now using current development has been fine, but once<br>
>> integrations (Rhino v6 and Grasshopper - we're *hoping* to get that out<br>
>> during summer) are out there with the public it'd be good to have a<br>
>> clear release and versioning system in place, especially for continued<br>
>> development after that.<br>
>><br>
>> If there is any syncing work that could be divided amongst active Cycles<br>
>> repository users and devs then that might help with getting a good<br>
>> handle on the progress.<br>
>><br>
>> I can at least handle part of the syncing etc., but I'd prefer not to be<br>
>> the only one here ;)<br>
>><br>
>> /Nathan<br>
>><br>
>> On 3/29/2016 10:35 AM, Sergey Sharybin wrote:<br>
>>> Hey,<br>
>>><br>
>>> @Thomas,<br>
>>><br>
>>>> Why wait for Blender to do a RC / Release, if we feel that the Cycles<br>
>>> side is stable already and justifies a new release?<br>
>>><br>
>>> Because all active Cycles developers are Blender guys and having extra<br>
>>> release to worry about (test, tag etc) inbetween of Blender's release is<br>
>>> kinda extra stress.<br>
>>><br>
>>> I'm not saying we can't do more releases than Blender, but currently we<br>
>>> don't have enough man power to properly cover that and making releases<br>
>>> in sync with Blender is just easier.<br>
>>><br>
>>> We can release more often later anyway.<br>
>>><br>
>>>> I would basically go with your suggestion of "Have release branches"<br>
>>> Same preference here actually.<br>
>>><br>
>>>> In other words, we can create a branch at the same time Blender or do<br>
>>> it in between at any other time, if we feel like it.<br>
>>><br>
>>> Yes, exactly. Or do a corrective releases inbetween. Or whatever. But<br>
>>> exactly "if we feel like it". As said before, having releases in sync is<br>
>>> just gonna be easier for the time being.<br>
>>><br>
>>> Once we'll figure out what exact way we'll want to go in this topic,<br>
>>> would you volunteer to help coordinating the work in standalone repo? ;)<br>
>>><br>
>>> @Mohamed,<br>
>>><br>
>>>> I would suggest developing Cycles alone with its own branches, and<br>
>>> merging this into Blender.<br>
>>><br>
>>> We don't have manpower for that and as mentioned above: majority of<br>
>>> Cycles contributors are heavily working on Blender anyway. Moving<br>
>>> development outside of Blender will just cause extra overhead for movie<br>
>>> Blender itself forward. For until there'll be stronger community around<br>
>>> Cycles's master branch i wouldn't really accept a model where Blender<br>
>>> developers would need to go into a hassle of developing something<br>
>>> externally and then re-merge the feature.<br>
>>><br>
>>> ---<br>
>>><br>
>>> As for version: wouldn't really call it 0.1 increments, more like second<br>
>>> octet increments? Meaning, we go from 1.9 to 1.10 (instead of 2.0)<br>
>>> unless we made some really major refactor?<br>
>>><br>
>>> Where to start counting i don't really care that much, just personal<br>
>>> opinion that starting release of 1.7 is kinda marketing, but i can leave<br>
>>> with that.<br>
>>><br>
>>><br>
>>> On Mon, Mar 28, 2016 at 10:42 PM, Mohamed Sakr <<a href="mailto:3dsakr@gmail.com">3dsakr@gmail.com</a><br>
>>> <mailto:<a href="mailto:3dsakr@gmail.com">3dsakr@gmail.com</a>>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> a great topic.<br>
>>> I would suggest developing Cycles alone with its own branches, and<br>
>>> merging this into Blender.<br>
>>> this will help in the future to Cycles Standalone, also porting it<br>
>>> will be steady as Cycles will be the main pivot, at moment Blender<br>
>>> is the main pivot.<br>
>>> about versions, as DingTo said: 0.1 per Blender release sounds<br>
>>> reasonable "assuming blender goes 10 releases every about 20 months<br>
>>> (if I'm not wrong), this makes a good version step".<br>
>>> version 1.0 looks young too, Cycles is production ready from long<br>
>>> ago, though it got many parts that needs pushing, but the stable<br>
>>> parts are already proven for production.<br>
>>><br>
>>> cheers,<br>
>>> Mohamed Sakr<br>
>>><br>
>>> On Mon, Mar 28, 2016 at 10:29 PM, Thomas Dinges <<a href="mailto:blender@dingto.org">blender@dingto.org</a><br>
>>> <mailto:<a href="mailto:blender@dingto.org">blender@dingto.org</a>>> wrote:<br>
>>><br>
>>> Hi,<br>
>>> that is an interesting topic.<br>
>>><br>
>>> My opinion here is, that we should have our own independent<br>
>>> release schedule and version scheme for Cycles.<br>
>>> I might be wrong, but it already happened, that we didn't really<br>
>>> add new stuff to Cycles for a bit and focused on other Blender<br>
>>> related things. Why wait for Blender to do a RC / Release, if we<br>
>>> feel that the Cycles side is stable already and justifies a new<br>
>>> release?<br>
>>><br>
>>> I would basically go with your suggestion of "Have release<br>
>>> branches" but stay independent of Blender here. In other words,<br>
>>> we can create a branch at the same time Blender or do it in<br>
>>> between at any other time, if we feel like it.<br>
>>><br>
>>> As for the versioning scheme, I always imagined it like taking a<br>
>>> 0.1 step per Blender release.<br>
>>> Blender 2.61 = Cycles 0.1<br>
>>> Blender 2.71 = Cycles 1.1<br>
>>> Blender 2.77 = Cycles 1.7<br>
>>><br>
>>> Anyway I would be fine either way, whether the first Cycles<br>
>>> release will be 1.0 or e.g. 1.7, even though I think that 1.0<br>
>>> sounds a bit too young, the engine is certainly beyond that. :)<br>
>>><br>
>>> Best regards,<br>
>>> Thomas<br>
>>><br>
>>><br>
>>><br>
>>> Am 28.03.2016 um 19:10 schrieb Sergey Sharybin:<br>
>>>> Hey,<br>
>>>><br>
>>>> = Preamble =<br>
>>>><br>
>>>> Some time ago we had IRC discussion with Nathan about tagging<br>
>>>> Cycles's repository once Blender gets a new release. At that<br>
>>>> time as i understood main reasoning was to make it real clear<br>
>>>> which revisions of Cycles repository are considered stable and<br>
>>>> which could cause you a troubles due to WIP features.<br>
>>>><br>
>>>> = Issues =<br>
>>>><br>
>>>> While it's all legit idea and something we should definitely<br>
>>>> have, it's a bit more tricky in implementation since the<br>
>>>> following reasons:<br>
>>>><br>
>>>> 1. Code freeze periods<br>
>>>> 2. Need tag name convention<br>
>>>><br>
>>>> First issue is coming from the fact that in Blender we're<br>
>>>> doing a release branch at the RC time. There's no new features<br>
>>>> committed to that branch (only bug fixes), but non-intrusive<br>
>>>> work continues on master branch after Blender RC1 is out.<br>
>>>><br>
>>>> In Cycles we've got a single branch, which with current<br>
>>>> situation will mean we wouldn't be able to synchronize any of<br>
>>>> the new code from Blender to Cycles during the RC period of<br>
>>>> Blender (which could be 3-4 weeks easily). That's something to<br>
>>>> be avoid in fact.<br>
>>>><br>
>>>> Second issue is more a convention. We would just need to agree<br>
>>>> on version system. I just don't feel like using Blender's<br>
>>>> versions for Cycles -- while releases can totally be<br>
>>>> synchronized, to me it makes more sense to have own versions<br>
>>>> for Cycles.<br>
>>>><br>
>>>> = Ideas =<br>
>>>><br>
>>>> Looking on all that here are couple of ideas how we can move<br>
>>>> forward.<br>
>>>><br>
>>>> == New branch: devel ==<br>
>>>><br>
>>>> The idea is simple: we move all on-going development in<br>
>>>> Cycles's standalone repository to a new branch called `devel`.<br>
>>>> Technically it'll mean we'll synchronize commits from Blender<br>
>>>> NOT to master but to devel branch.<br>
>>>><br>
>>>> Once Blender is released we'll fast-forward devel branch to<br>
>>>> master.<br>
>>>><br>
>>>> As simple as that. That would solve requirement of<br>
>>>> distinguishing stable Cycles from ongoing development one.<br>
>>>> Additionally, we'll be able to tag master branch with<br>
>>>> annotated release tags. Read about that in next ideas.<br>
>>>><br>
>>>> == Have release branches ==<br>
>>>><br>
>>>> Other idea is to follow Blender's release process and keep all<br>
>>>> development happening in Cycles standalone in the master<br>
>>>> branch and once Blender get's RC branch we create same thing<br>
>>>> in Cycles. All crucial bugfixes will be cherry-picked to that<br>
>>>> branch and when blender releases we'll tag the branch in<br>
>>>> standalone repository and delete the branch (so we'll leave<br>
>>>> with just tags).<br>
>>>><br>
>>>> == Tagging / versions ==<br>
>>>><br>
>>>> Here i propose to consider first tag 1.0, and next releases<br>
>>>> will be 1.1, 1.2 ... and so on, for until we do some major<br>
>>>> re-consideration in Cycles (going bi-dir?) which would start<br>
>>>> 2.0 version.<br>
>>>><br>
>>>> I personal opinion that'd be natural for external users /<br>
>>>> developers of Cycles.<br>
>>>><br>
>>>> = Comments? +<br>
>>>><br>
>>>> Now, i'm wondering what other both Cycles core developers and<br>
>>>> external developers who integrates Cycles in other software<br>
>>>> think of how we should process. Maybe i'm all wrong, thinking<br>
>>>> too much or maybe you guys will like one of the ideas here.<br>
>>>><br>
>>>> Let's have a bit of communication/discussion here before<br>
>>>> changing the way we operate with standalone Cycles repo!<br>
>>>><br>
>>>> P.S. Sorry for the lengthy mail..<br>
>>>><br>
>>>> --<br>
>>>> With best regards, Sergey Sharybin<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Bf-cycles mailing list<br>
>>>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a> <mailto:<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>><br>
>>>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Bf-cycles mailing list<br>
>>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a> <mailto:<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>><br>
>>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Bf-cycles mailing list<br>
>>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a> <mailto:<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>><br>
>>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> With best regards, Sergey Sharybin<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Bf-cycles mailing list<br>
>>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>>><br>
>><br>
>> --<br>
>> Nathan Letwory<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Bf-cycles mailing list<br>
>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
>><br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><span style="color:rgb(102,102,102)">With best regards, Sergey Sharybin</span></div></div>
</div>