[Bf-cycles] Cycles releases
Sergey Sharybin
sergey.vfx at gmail.com
Tue Apr 5 17:23:50 CEST 2016
Hi,
There is now v1.7.0 tag in the repository which corresponds to Cycles we
shipped in Blender 2.77.
There's also a temporary(?) cycles-v1.7.0-release branch where commits
backport happened. We can keep it if it's useful or can simply remove after
we've done with 1.7 series (which would totally mimmic release process of
Blender itself, where branch is only used temporary).
On Thu, Mar 31, 2016 at 10:43 AM, Nathan Letwory <nathan at mcneel.com> wrote:
> Thanks all for the effort,
>
> much appreciated :)
>
> /Nathan
>
> On 3/31/2016 10:54 AM, Sergey Sharybin wrote:
> > Thomas,
> >
> > Cool! Did some tweaks tho, so compilation wouldn't fail.
> >
> > Will create real 1.7.0 tag later today (so you can grab exact Cycles
> > code which we shipped in Blender 2.77).
> >
> > And eventually we can go ahead and tag all previous releases actually.
> >
> > On Thu, Mar 31, 2016 at 1:24 AM, Thomas Dinges <blender at dingto.org
> > <mailto:blender at dingto.org>> wrote:
> >
> > 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 <mailto: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>
> > >>> <mailto: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>
> > >>> <mailto: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
>
>
> --
> Nathan Letwory
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
--
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160405/6434db8b/attachment.htm
More information about the Bf-cycles
mailing list