<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
that is an interesting topic. <br>
<br>
My opinion here is, that we should have our own independent release
schedule and version scheme for Cycles. <br>
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? <br>
<br>
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. <br>
<br>
As for the versioning scheme, I always imagined it like taking a 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 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. :) <br>
<br>
Best regards,<br>
Thomas<br>
<br>
<br>
<div class="moz-cite-prefix">Am 28.03.2016 um 19:10 schrieb Sergey
Sharybin:<br>
</div>
<blockquote
cite="mid:CAErtv27=Sq_92ZwnAsADobWEKXkixO2=eRp5YS6DTbGjDBtSeA@mail.gmail.com"
type="cite">
<div dir="ltr">Hey,
<div><br>
</div>
<div>= Preamble =</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>= Issues =</div>
<div><br>
</div>
<div>While it's all legit idea and something we should
definitely have, it's a bit more tricky in implementation
since the following reasons:</div>
<div><br>
</div>
<div>1. Code freeze periods</div>
<div>2. Need tag name convention</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>= Ideas =</div>
<div><br>
</div>
<div>Looking on all that here are couple of ideas how we can
move forward.</div>
<div><br>
</div>
<div>== New branch: devel ==</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Once Blender is released we'll fast-forward devel branch to
master.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>== Have release branches ==</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>== Tagging / versions ==</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I personal opinion that'd be natural for external users /
developers of Cycles.</div>
<div><br>
</div>
<div>= Comments? +<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Let's have a bit of communication/discussion here before
changing the way we operate with standalone Cycles repo!</div>
<div><br>
</div>
<div>P.S. Sorry for the lengthy mail..</div>
<div><br>
</div>
<div>-- <br>
<div class="gmail_signature">
<div><span style="color:rgb(102,102,102)">With best regards,
Sergey Sharybin</span></div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-cycles mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a>
<a class="moz-txt-link-freetext" href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</body>
</html>