[Bf-cycles] Cycles releases
Nathan Letwory
nathan at mcneel.com
Thu Mar 31 10:43:14 CEST 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.blender.org/pipermail/bf-cycles/attachments/20160331/3bfb8f9b/attachment.pgp
More information about the Bf-cycles
mailing list