A more iterative development/release process

[Anonymous]

No software is bug free, this is a fact. But, software that addresses these issues quickly will be all the better for it. Previously Maya had a standard development cycle: initial year release with a set feature list followed by several Service Pack and Hotfix builds to correct issues in that base package. New features within a generation would be released as an Extension Pack. Fast forward to Maya 2017+ and this system has been replaced by Updates, where a base year release is put out followed by Updates that introduce bug fixes and new features. While the merits of these two strategies can be debated at length, the latter is here to stay. That being said, the timeline between updates is much to long for simple issues that crop up in each release/Update, particularly workflow breaking issues that are identified on day one.

Maya already follows a slight variant of semantic versioning, for example Maya 2018.2. My proposition is simple (unless the Maya build system/CI is infinitely more complex than every other industry tool, which I strongly doubt it is). Bring back hotfixes that can address issues with major/minor releases that can installed by the user and increment the patch value. Put them out as weekly builds, or however you see it. I wouldn't mind having to re-download a gigabyte of material if it fixes an issue I am having. But the way the current system stands it's not ideal for development and feedback. If an issue is identified that breaks workflows, I'm rolling back or not updating. This means fewer users are providing valuable feedback on the current release. And then waiting several months just to see if these issues have been solved.

By introducing a more iterative build process provides a multitude of positives, but the main ones are these: customer satisfaction and improved development. Customers will be able to continue working with latest without show stopping issues and the dev team will receive valuable and complete feedback. A system like that of SideFX's Houdini (though I'm not asking for daily builds) works really well because it identifies targets that should be used for production, but then lets the user at their discretion to use an unofficial 'non-stable' build if it fixes an issue they are having. Similarly Redshift has weekly builds (that are official) and the development is very well received as issues are identified and removed at breathtaking speed. This overwhelming improves the user experience of an application and allows us to forget about checking to see if a new build has come out or praying for our issues to show up in the release notes of a version. Allow the Maya team to be more agile and you'll see a new vested interest in the app by the user base.

Cheers,

Mike

[pavelR.]

the "Maya Updates" are advertised by Autodesk as if they are providing 'quicker fixes', which is not the case.

Quote:

Maya 2017 marks a shift in the way Maya is maintained and updated to provide quicker access to new features, and quicker fixes to customer issues.

Source: https://knowledge.autodesk.com/sites/default/files/Maya_2017_Update1_Readme_enu.htm

There is no need to have a daily build system but it can't be that on severe issues (reminder: 2GB file issue and others)  users are left alone for months with a problem, probably even stopping them to use the current version. In some cases a fallback to a older version is not an option due to compatibility and since introducing the full-update-replacement installers the average user it is not able to maintain two Maya versions at the same time, because on each subsequent update the other gets replaced (2018.2 and 2018.3 sidebyside, it is possible despite claimed otherwise but requires a user who is comfortable/techsavvy with his choice of Operating System)

As much as we (users) hate them, but regression bugs do happen... but there is no need to have to wait ..say.. 5 months? until it is *maybe* fixed.

And when features do get deprecated, other parts of the application are are supposed to be compatible, and if not, it is also worth a hotfix and not 'wait' almost half a year to have them maybe addressed in an upcoming update.

Being able to push out more frequent updates to issues (as the post above already mentioned, which are often enough spotted on the first day of the 'update' release) is crucial if you want to have users make actually use of this application, and bigger companies may be not as shy with updates either (probably the other reason why subscriptions was introduced was to 'motivate' studios to update to a newer version rather than clinging to their old, but functional, version... among "other" reasons)

From a user point of view it would justify a monthly fee (partly even this excessive EU pricing..) for a maintained product, if there is a noticeable an d frequent update support going on. The current situation, at least for me, is the constant fear that something might break and maybe never be fixed, currently Autodesk is working on 2019 while 2018.3 isn't really polished. 

Rather than pushing features (see post above) it should be a higher priority to push bugfixes to have the current feature set fully functional. Features can be added in major-version updates, so they get at least a chance to be polished and well-implemented on the next major release.

If Autodesk feels that there is still need to keep pushing new features via updates, fine, but then don't have the users sit and wait for months until (hot-)fixes/issues are addressed on the next so called 'update'.

You wouldn't want to pay a monthly fee for a leased car (that's what subscription is, isn't it..) that suffers from issues but would instead expect that things get fixed, otherwise the leasing contract might be questioned... just a real-world example.. software ain't much different.

[Anonymous]

Great statement @pavelR.. This is really the issue I'm pushing, the problem of regressions. I understand that each Update has a set of targets that need to be reached for release. But, if an Update introduces regressions and breaks things that were previously working fine, it needs to be fixed in that Update's lifespan. Not the next one, but a patch applied to that update. As customers, we are paying monthly, annually, and multi-annually for the tools to work and be maintained. I do appreciate the new features over the course of a major version's lifespan, but they can't be at the cost of existing functionality. That functionality needs to be maintained, and if broken, rectified as soon as possible. I'm more concerned with working features that break after an Update than features that have been broken that I know will be fixed in time.

Cheers,

Mike