If it is unacceptable, what did you do to improve this?
It is purely lack of manpower to it all, the developers have to create spear points where the developers focus their time on.
We can not expect the few developers to carry everything we through at them.
Providing an addon?
Nice,… but addons need to be maintained as well, and if nobody does this, these get left behind.
It is a community solution, do you like an Addon which got left behind, what did you do to help getting it up to date?
In other words: someone has to pull the load, the developers do this, we have to help to push the load.
And what the developers miss out on, is up to the community.
So saying this is unacceptable is basically the same as saying, you all go on, I will make sure this gets done right.
mainly: manpower and funds to pay for manpower… solves it all.
I’m lamenting it here, which is about all I can do. In this case this is not about manpower but about a general tendency (a philosophy if you wish) to “just break things” instead of deprecating things and then phasing them out.
It is one thing if we have script that maybe the community can fix (which may or may not actually happen) or if you are a company that wants to support blender and cannot just rely on the community to fix things for them. Also, some stuff simply may not get developed in the first place because of this reputation that blender has now.
I am sure you can do better then this.
It is not that the developers aren’t aware of this. But as mentioned before: they only can do so much, like we all are limited in what we can. But I am sure there is more possible then pointing things out. I am just pointing this out, as I did before.
But without joking around: we all can do more then we think, only if we took the time to give ourselves a chance to improve and contribute.
I feels good to contribute!
The changes made were all very essential and as Blender matures more and more over time, more will be possible.
But with a major change like the last period Blender has undergone, it isn’t so bad.
The benefits outweigh the downsides.
I understand future promises of stability are essential.
But the differences from 2.49 to now are of such a huge impact that we can’ t hold the Blender Foundations and other developers accountable for that functionality we lost.
I agree that future stability is important.
But on the other hand every version is still available and fully functional, so for (commercial) production use any of the version which you prefer. For the other versions, you either actively make a contribution to change it for the better yourself, or be grateful and wait patiently.
That is how community software fucntions: like or change it yourself. And we must be proud of that this is possible and results in such a great application!
You are saying essentially the same thing over and over and over, but you are wrong. In this case there is nothing I can do. (Except complain about it and lay out my arguments)
Yeah but it simply doesn’t work like that in this case. What am I supposed to do, fork blender and declare my fork to be “stable” and make everybody develop for my fork instead of the official one? That’s nonsense. This isn’t something that can be solved by the community. The developers responsible need to change the way they think. Stop breaking things all the time!
But the differences from 2.49 to now are of such a huge impact that we can’ t hold the Blender Foundations and other developers accountable for that functionality we lost.
I’m not talking about the switch from 2.49 (in which it was justified to break things) but the fact that in pretty much every release since then stuff was changed that broke some things.
Yeah. That’s right. They just want to break things, just to piss you off.
Okay Zalamander. You have a beef with the recent changes in the python API. We get it.
This has nothing to do with open source. It happens in commercial apps as well. How many MEL scripts can survive several releases of Maya? Only the very simplest ones. Commercial apps have the budget to pay for extensive promotion and documentation of new features and changes, but they definitely still break compatibility.
Crumpet is right; if you have an issue you want to solve, the onus is on to you to do the research and ask the right people the right questions. That’s the cost of using open source. On the up side, you’ll learn something and end up with more control over the software you use.
You can perceive everything between 2.49 and 2.7?? as in-between versions, a transition to the new set up. (basically everything between 2 and 3 is a subversion?)
I remember the software update of 3ds Max,… a very expensive license as you may know,… I received my update/upgrade by Autodesk, went to work with it like many others,… then to discover that every file you saved couldn’t be opened anymore… what is their excuse?
Well it is how it is, you accept the losses and try to do some damage control and continue.
Blender is for free and yes you can do more then complain.
You can get the developer some coffee, make sure they are well rested and do not get down because they read all negative feedback, while they work so hard.
You can donate money, hire a developer yourself, or step up and do it yourself.
While with proprietary software, like the above example, there is very little you can do, but wait.
You paid your dues (license+subscription), what rests is you wait until they fix it for you.
With Open Source the beauty is you can actively make a change and speed things up.
And where you have to abandon because of lack of knowledge, or while waiting it gets included into trunk, you can make sure nothing distracts the developer who you depend on. Make sure that everything on the forums and other communications means are clean and tight, so they do not need to spend to read about anything that doesn’t help them perform.
If nothing else, investigate the problem, work it out as far as you can, provide a solution, give the developer a compliment or two to get their positive vibe back, buy them a coffee and give them a decent neck massage.
I don’t know about Maya/MEL, but most commercial applications have a period of depreciation when they make API changes to give people a grace period to update their scripts. They’ll add a new method, and keep the old one, but have the old one throw a warning that it’s depreciated in favor of the new method or whatever. The script doesn’t break unexpectedly, it communicates how to fix it going in the future, and gives them time to do it.
Blender outright breaks things with little to no warning, in combination with releasing every 2 months. That isn’t very sustainable for many people. Besides breaking the API so often really begins to defeat the purpose of having an API in the first place.
I don’t think it’s realistically possible to avoid it all the time, but it could be handled a lot better than it has been.
I said it’s a symptom of open-source, probably because of the idea that “if something is wrong, people can change it right?”. Yes, sure they can. But in practice, they probably won’t.
It happens in commercial apps as well. How many MEL scripts can survive several releases of Maya? Only the very simplest ones. Commercial apps have the budget to pay for extensive promotion and documentation of new features and changes, but they definitely still break compatibility.
I’m not a Maya user, so I don’t know about their situation. But how much time is “several releases” in Maya terms? Blender is currently on an eight-week release cycle, Maya on a yearly one. I don’t believe the problem is nearly as big as it is for Blender.
Crumpet is right; if you have an issue you want to solve, the onus is on to you to do the research and ask the right people the right questions. That’s the cost of using open source. On the up side, you’ll learn something and end up with more control over the software you use.
Ok for the last time, this is an argument that doesn’t apply in this case. Repeating it like a mantra doesn’t work. We have developers complaining here that they can’t spend time on developing for an API that is unstable. That’s just a fact, okay? If you where so kind to explain what sort research and asking and learning on my side would change anything about that situation?
Here’s the thing. No one is forcing you to use the latest version of Blender. If a script you use works in an older version, use that version. With commercial software, it’s unlikely that you’ll have multiple versions of the same program available to you (for a variety of reasons; not the least of which is the expense). It’s not uncommon for small shops to lock a production to a specific version of a piece of software until the production is complete. Hell, there are still a few projects I have that require me to use Blender 2.49b. Yes, Blender’s release schedule is much faster than other programs, but you’re not compelled to use the latest release. If you want to stick with the most recent version (or, like some of us, the most recent commit to trunk :P), you’re going to have to play a much active part in following (and sometimes contributing to) Blender development.
If a script you use works in an older version, use that version.
Fair enough, that’s not a completely invalid argument to a user. However it’s not very nice to be forced to do that. It’s not like you can pick and choose what you want from an update, it may fix a bug you can’t work around or bring a new feature that you would really like to use but now can’t.
To a software vendor that wants to integrate into blender it is however not a very good situation, because the users will constantly be running to them to demand the newest version to be supported. You wouldn’t want to run the risk of making an impression that you don’t care about your users by not providing the necessary updates, so you might just prefer to simply stay away from integrating with blender altogether.
There sometimes are good reasons to break things, but with blender often changes are very arbitrary (e.g. moving things around without leaving aliases or changing the row order of matrices) and unplanned, so it just gives a developer the impression that there is a disregard for the necessity of maintaining a stable API. If your API has the reputation of being unstable, some development will simply not happen in the first place.
Indeed. For many projects, even big commercial movie productions, the software version is fixed at the start, and no one upgrades until it is complete.
I have to keep multiple versions of Blender installed, because I have old client projects that have to be used again from time to time. No reason to update those, they keep working just fine.
How many versions of Blender does a person need to have installed before it starts to become ridiculous though?
It would be understandable if there was actually a real advantage to it. Breaking API’s all the time is only really going to make it more difficult for third parties to support Blender. Which is kind of the point of maintaining an API in the first place. Third party support isn’t exactly Blender’s strength as it is. -shrug-
One issue is that the 2.5 series was beta and it should have been known that changes were happening. Now bmesh is throwing a monkeywrench into the works, but it could end up being a big plus that tools that were once addons will be more easily hardcoded. Not to make excuses, it must suck to have scripts break, but at the same time you are in the wrong game if you hate change (or maybe just write addons for gimp* ). Even at a user level it’s tough to keep up with the pace of development at times, but that’s part of the fun I think.
If an external library was used to do import/export, Assimp (where do OSS programmers find their names?) perhaps, making the add-on much simpler to maintain? People interested in this arcane speciality could congregate there, with the added bonus we can blame them instead of Blender’s developers.
A plugin system and a release per year could be better, for users,and for development not made by the foundation,but outside(like scripts)
But it will never happen,from a marketing point of view the more releases you do the better is.
This whole time since 2.5 the devs said there’s no point in writing tools since bmesh would break them. And now the people who went and wrote scripts anyway despite the warning are angry because bmesh did exactly what was predicted it would do. I don’t know what to say to that.
We all understand the raised problem and understand the consequences for us all.
But as it reads through here: it seems that most of us have our peace with the current situation.
If there is nothing you feel you can do, you can try to join any meeting and try to get your points of interest on the agenda.
Talk it over with the dev’s.
But I am sure the dev’s exactly know what is happening and are aware of the consequences and made a decision, because they have to decide and continue looking forward.
Acceptance might be the only solution if you aren’t capable of making any positive change yourself, if you depend on others, patience might be the answer.
short release cycles are far easier from a debugging and integration perspective. A release every 2-3 months has 1/6th the new features of a release every year. Which means fewer potential negative interactions between new features, more testing of those features (users only ‘really’ test right before a release or more often right after); also there is a great deal less frustration from a new developers (their new feature can go in in a few months instead of 6 months); and we can avoid putting in features that aren’t quite complete so that they make a release cycle deadline - they can fairly safely be pushed back to the next release with only a month delay or so before going into head.
The only downside is that there is slightly more overhead to do multiple small releases than one big release.
). Even at a user level it’s tough to keep up with the pace of development at times, but that’s part of the fun I think.