<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey Sergey,<br>
yes I can help coordinating that, fine with it. :) <br>
<br>
As for the releases, of course this depends on available manpower
and demand from external parties. We will see about the schedule. <br>
<br>
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. <br>
Probably Brecht should have the final word on this, he is the
creator after all! :) <br>
<br>
Best regards,<br>
Thomas<br>
<br>
<div class="moz-cite-prefix">Am 29.03.2016 um 09:35 schrieb Sergey
Sharybin:<br>
</div>
<blockquote
cite="mid:CAErtv27ORW0fbfOydfu1ZF6aJKApvW+tFCGwMxAKd3a=3ycbBA@mail.gmail.com"
type="cite">
<div dir="ltr">Hey,
<div><br>
</div>
<div>@Thomas, </div>
<div><br>
</div>
<div>> Why wait for Blender to do a RC / Release, if we feel
that the Cycles side is stable already and justifies a new
release?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>We can release more often later anyway.</div>
<div><br>
</div>
<div>> I would basically go with your suggestion of "Have
release branches"</div>
<div><br>
</div>
<div>Same preference here actually.</div>
<div><br>
</div>
<div>> 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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? ;)</div>
<div><br>
</div>
<div>@Mohamed,<br>
</div>
<div><br>
</div>
<div>> I would suggest developing Cycles alone with its own
branches, and merging this into Blender.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>---</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 28, 2016 at 10:42 PM,
Mohamed Sakr <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:3dsakr@gmail.com" target="_blank">3dsakr@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi,
<div><br>
a great topic.<br>
I would suggest developing Cycles alone with its own
branches, and merging this into Blender.<br>
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.<br>
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".<br>
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.<br>
<br>
cheers,<br>
Mohamed Sakr</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 28, 2016 at 10:29
PM, Thomas Dinges <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:blender@dingto.org" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:blender@dingto.org">blender@dingto.org</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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
<div>
<div><br>
<br>
<br>
<div>Am 28.03.2016 um 19:10 schrieb Sergey
Sharybin:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<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>
<div><span
style="color:rgb(102,102,102)">With
best regards, Sergey Sharybin</span></div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Bf-cycles mailing list
<a moz-do-not-send="true" href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a>
<a moz-do-not-send="true" href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bf-cycles@blender.org"
target="_blank">Bf-cycles@blender.org</a><br>
<a moz-do-not-send="true"
href="http://lists.blender.org/mailman/listinfo/bf-cycles"
rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a moz-do-not-send="true"
href="http://lists.blender.org/mailman/listinfo/bf-cycles"
rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br>
</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>
<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>