After reading about the need for an ‘a’ release again, there’s been a discussion on the mailing list on how to improve the cycle so it improves the quality of releases and makes it easier for devs. and users alike.
Ton initially came out in opposition to most of the proposals, but stated that he wasn’t thinking at peak performance due to jetlag and summertime heat, now that he has regrouped his thoughts, here’s his opinion.
Hi Cam,
Yep we gotta move on. Was suffering jetlag and few days heatwave in Amsterdam
Reading all comments, I think there’s consensus to:
Do the usual test build in BCon4 period, just a snapshot of trunk
Make a real RC, which is the tagged release branch (with splash, release nr, etc)
Do the actual release some weeks after with bugfixes in this branch. (or an RC2, etc, until all is fine).
Which is your ‘renaming’ proposal, which I didn’t get at first. Jetlag
Further actions to take:
Actively remind module owners to at least do serious tests of their areas. It’s really part of the responsibility that comes with ownership.
Get the regression files upgraded (better ones, not more files!)
Investigate various ways for automatic testing
About bi-monthly planning:
I think we’re getting a bit release-fatigue now. Pushing a release just because the planning says so isn’t very inspiring. We can still do a serious attempt to release as often as possible, but let’s base it on a planning that reflects our code work best - branch mergers and refactors should get fair amount of time too.
A useful rule-of-thumb could be to schedule an official new “RC release” two months after the real stable release, which would in practice be a 2.5 to 3 months cycle. We can define this each time on a per-case basis though.
This sounds like a plan to me as well, in part because developers will no longer be feeling pressure (or at least not as much pressure) to get their stuff in trunk in time for the release because they will be more or less be using a real release branch with trunk continuing to be open for new development.
Ugh, I really wish that BF would only release one “official” version every six months at most as to make it easier for the plugin developers and most likely the devs themselves.
I’ve said this before but I think one of the issues with people not hammering the RC’s and subsequently the need arising for an “A” and “B” releases may be due to the fact that development of new features continues on during that period. In the last few releases, as soon as the RC is out, there is suddenly a bunch of new features that turn up in the trunk. So, advanced users (the ones who make a lot of bug reports by the way) will tend to download and use build bot or home built versions to test out these new features. So I think a lot of attention gets taken away from the RC because of this.
I think the solution is to “Freeze” development of new features in trunk during the RC release. I think this will help a lot with getting more people to help out testing the RC’s.
** Another thing is, why is this even an issue in the first place? I mean, what’s the problem with an A and B release? It’s not like I’m cursing Blender foundation for fixing things. I’m happy to download a newer more stable version! If this was commercial software, I could see the concern. They only have one or two releases a year and everything needs to be rock solid or users will be unhappy and you’ll loose money. But this is an open source project that is continually evolving. If there is a bug in the newest version, you report is and a few days later there might be a fix for it. With commercial software, this might be 6 months to a year until you see a fix. I guess I’m wondering if the whole paradigm of a “Release” schedule is even a valid concern for a project like Blender?
** And another thing is that if the release paradigm is valid then where are the “Beta” testers? With every commercial software, there is a core group of people who are constantly working with the developers looking for bugs. You could argue that we are all beta testers but I’m talking about a more focused group of individuals who are only looking for bugs. The devs would be constantly dealing directly with them to get features hammered out.
Yet another issue I see is that once a few feature or fix is commited, it’s basically up to the users to see that it’s there. Sometimes there is a note about it in a thread here and there but in general, if a developer adds a new feature and is wants people to test it, simply using the commit logs is kind of like shouting into an empty room in many cases. I don’t know what the solution to that is though…
** Maybe a formation of a core beta team is needed and a clearer way to find out when a fix has been issued and when a new feature is added other then having to wade through the commit logs. The commit logs are great but there is a lot of technical speak in there and it’s not always clear whether something is a fix, new feature, cleanup or just some maintenance. I would love to see some way of categorizing or filtering the commit logs and have them displayed on a clean and clear to read web page.
The BF already had a period a number of years ago where the release cycle stretched to at least 6 months (in the latter half of the 2.4x series), this did not entirely eliminate the need to do ‘a’ releases or even an entire release devoted to restore stability and fix bugs (2.46). It doesn’t matter how long the release cycle is, people will still find showstoppers in the official release builds if people aren’t banging on the RC’s.
As for the paradigm of a release schedule for an open source project, I think there’s many here that like the fact that they can predict when the next release will be, look at other FOSS projects and you’re left with a constant question mark over your head because you don’t know if the next release will be next month or next year. Plus it makes Blender development act more like commercial software which many of them have predictable and reliable release cycles.
Just to be clear, I am not talking about limiting the release cycle entirely to only two releases a year, they can still do bi-monthly releases and nightly builds but call them “beta-releases” or something to indicate ongoing development and non-stable releases. Those releases can be the testing stages and then the two official releases can be the final ones that plugin-developers need to concern themselves with.
What I am talking about doesn’t really have anything to do with bug fixes at all really, I am only concerned about the plugin-developers having to update their scripts every week to keep up with the release cycle of BF.
I also agree that developers should get at least about 4 months. Releases HAVE to be to let coders work in the best possible manner. Releases may happen each 3 to 4 months, but there should be semester or even year style goals, like big features.
I can certainly understand that. I’m just posing the question to everyone. Is it really valid anymore? And should be really be moving toward a more commercial model? I fell like we have something that is better than that but we don’t even realize it.
To be honest, I don’t really attention to the blender releases because I usually build a new version for myself whenever I want. And even if that wasn’t the case, I can just go download the latest build from builder.blender.org. Often times new features are added to Blender at the beginning or the middle of the release schedule. Most of the time, they are only updated a little here and there as bugs a found but that’s pretty much it. Why wait for those features if they can help you out right now? This is the very advantage that Blender has over commercial software. So, I just feel like it’s of little consequence when a release happens because feels more superficial then anything else. I can totally understand wanting to set goals and deadlines for certain features though. Maybe they can introduce a milestone system where the development continues but there are defined states that the software needs to be in by e specific date? I don’t know, I’m just throwing that out there.
Hmm, yes this is something I hadn’t considered. But then again, this sounds like a separate issue. Like there needs to be a period of time where they don’t do any API breaking changes for a set amount of time and then at a specific date, they say “Oaky what API changes really need to happen in order to move forward?” and they go for it. That will be a day 3rd party developers will hate but maybe it only happens once a year?
Regardless of release cycle, APIs shouldn’t break, period. Stuff should be properly deprecated, but not just removed or changed outright. It was acceptable during the beta stages, but I still don’t see a strong commitment to a stable API. Breaking decades-old files is considered a no-go for Blender development, so why is breaking the API acceptable?
It’s not like the API currently changes everywhere every release, anyway. Having to fix stuff up every year is a pain, just as well. Often enough, it’s simply not done, because people move on to other things. Apart from that, many users have to waste a lot time having to figure that a given addon/script doesn’t work because of API changes (as opposed to, say, user error).
Blender should adopt development methods more in line with the ones of commercial programs:
release date its-ready-when-its-ready not at a certain fixed calendar day (actually this is the OSS way, the fixed calendar day is the commercial one :no:);
2-3 releases at most in one year (developers are not hamsters running in their cage wheel) which is still faster than any other program which have a 12-24 months release cycles;
beta+rc phase with bug fix but mandatory feature freeze (no ifs or buts, it did not make in time, full stop);
service packs only to fix bugs and not out the next week (i.e., if you ignore beta/rc phase as an opportunity to test drive the program, be prepared to live for weeks with a bug…)
And, as many others wrote, once a plugin API is published, it is written in stone (many Java Date methods have been depracated a decade ago but are still available in 1.8!). The hamster-wheel/inevitable rot is preventing Blender to get a whole cottage industry of plugins like other programs (3DS, SketchUp etc. etc.). Imagine: no greeble plugins for 2.5/2.6…
Doesn’t make any sense. The rate of releases is irrelevant. My opinion is stop wasting time on new features and concentrate on fixing bugs and improving current features. I think Blender also needs to be improved in source code level, but when you think how open source projects often are managed it can be a difficult task.
The problem with release when its ready is it doesn’t scale well,
A project like blender encompasses many separate components internally, it becomes impractical to wait until they are all their developers have finished making changes, especially with volunteer developers.
We used to do this in 2.4x and it become quite frustrating - we couldn’t release because of … video-editor/game-engine/rendering-engine/collada/ffmpeg/some-guys-script… needed extra work.
Counter intuitively - what actually happens is developers have no sense of urgancy - take as long as they want with changes, trunk drifts towards becoming less stable between releases, each release contains many more, poorly tested changes, we do a release after 6months, and have a flood of bug reports (and an ‘a’ release) afterwards anyway.
So better to say to developers - your work is going to be ready by some DATE or not, if not you wait until the next releases merge window.
In fact we still have release when its ready internally, but it changes to merge when its ready.
Release candidate testing must be two weeks, not just 2 days.
While release candidate is out, there must be no commit to trunk, each developper must do his work in his own computer for two weeks without any commit to trunk. Then, when the commits start again there must be an order: First Campbell commit all he desires and then unlocks and other commits all he want, then other, then other. Not mixing commits until each developper ended the commits. This is to avoid everyone fixing commits and only will have to do it probably the last ones in commiting. This order will be a circle list so campbell would be then the last one next time after a release candidate in commiting.
I don’t know guys. I like the way it currently is. New stable realeases every 2 months, with a and b releases for added stability. In the commercial world they are called service packs. Release builds (especially a and b) are generally very stable and good for production. The rapid release schedule ensures that devs keep pushing to get their code finished in a timely manner, but if not, they have another 2 months to get it in for the next release.
Seriously… whats the big issue here? Sometimes I think the blender community holds blender up to a much higher standard than even the commercial world. I find blender to be generally more stable than maya, and with maya we have to wait months for simple bug fixes, if they get fixed at all.
I appreciate everyone’s desire to have an uber stable release that doesn’t have an ugly letter next to the number, but c’mon.
It keeps blender up to date without sinking into irrelevancy because something keeps pushing the release date further.
if I have an issue now,I can mostlycount on it that in 2 months it will be solved,usually. That is a huge benefit.
And I don’t mind a and b releases. I don’t think you can avoid them,nor maybe should you.
I do agree that having a model that is a bit more flexible is not a bad idea though. But I hope the releases won’t be slower and slower…
My opinion, is that the 2 month cycle moved into 3 month cycle so instead of 6 releases per year, we get 4 - two stable and two Intermediary. What with the label?
Simple, the moment a new Blender comes out, the old one doesn’t stop working, or can’t be downloaded from blender site. So plug-ins developer can tell their user that they only support ‘Stable’ version, no the ‘Intermediary’ version. Hence, they only need to worry twice per year.
We who are into this development shouldn’t force average users to follow suit. All they need to know is to download blender twice per year, or if their script didn’t break, the ‘Intermediary’ too.
Agree with Zalamander, the only thing add-on devs want is a stable API. Nobody working for no money on it’s free time can promise to update an add-on for years. And most of the time, nobody wants/can fix it without diving in another mindset (understanding someone elses code is really not funny). Please give us a stable API !!!
Its understandable that some users would be happy with a longer (~6month) release cycle,
But I don’t think this works well for development, and I’m quite sure it wouldn’t result in a more stable release.
For devs it gets pretty annoying if we have bugs fixes for many months and users keep reporting them,
The more frequent release means what users work with and what devs are running is less out of sync which greatly benefits Blender as a project IMHO.
For users that want more stability (less crashes) - I think we’re getting better - from 2.67 -> 2.68a we did around 290 bug fixes.
Consider with less frequent releases - users may wait another 4 months for these fixes - Which I don’t think helps users or devs.
As for API stability - Blenders API’s have been quite stable for last ~3 releases. I don’t buy the argument our API’s are unstable anymore.
There were several potentially script-breaking changes in the last 3 releases. In particular, what’s the point of some of these renamings? If the semantics don’t change, you shouldn’t just rename stuff, things will just break for no good reason. (Or am I missing something here?)
As I said, it’s not like the API changes completely with every release, but that I’m missing a commitment to a stable API. That means simply not changing the API unless there is a very good reason to do so.
