A discussion on our release cycles, timing, product naming

[Max]

Hey folks, I wanted to get some feedback before we make some final decisions internally and announce our plan more broadly.

With 2019 shipping on Monday and now that many of the structural things are out of the way, for example upgrading ACIS/graphics/import/export/DCM etc. we are in a good position moving forward.

We are considering the following:

• No longer having yearly "big major releases" a'la 2018.0, 2019.0 that take a ton of time to do, are difficult to QA, and are subject to slipping.
• Instead, we will ship at least every 4 months, with the goal of making each release approximately equal in terms of scope.
• We want to spread value delivery more evenly throughout the year, as well as get improvements to you faster.

This model would imply a different naming structure to the product. People expect the "2020 release" to be big. Since we are releasing more often, the concept of this huge yearly release wouldn't exist. So perhaps we might change the naming convention around to fit that.

That is not to say we wouldn't tackle some big stuff - those projects would just take 2 releases to actually get out the door. We feel delivering more often is consistent with previous feedback we've gotten on the forum, and this is a final check in to be sure this is what you want.

Thoughts?

 

[DavidJ]

Minimising slippage is good. Delays frustrate everybody.

Naming/numbering would need to be made very clear - and you'll need to make sure users can readily find out which version they are entitled to, and that they can download the installer (or an earlier one on the occasions that is needed). More releases per year has potential to lead to a bit of confusion if not made really clear. The year number and release number being one out of step already leads to some confusion.

Big stuff delivered over more than one update - may be hard to say exactly, but are you thinking new feature might initially be limited, then extend in next release OR background stuff built in at one release, then feature 'made public' at next release? Either could work.

Generally I like the sound of what you suggest - especially if it opens up the possibility of faster delivery on average for new capabilities.

To go along with this, management of the Help will need to be improved - it'll have to be updated more often, made easier to search, and have something added to indicate which levels of the software have access to each feature.

 

[Max]

Naming/numbering would need to be made very clear - and you'll need to make sure users can readily find out which version they are entitled to, and that they can download the installer (or an earlier one on the occasions that is needed). More releases per year has potential to lead to a bit of confusion if not made really clear. The year number and release number being one out of step already leads to some confusion.

There will still exist some internal, end-user visible identity structure. This is more for a marketing name. For example, perhaps the next release is called v1, then v2, then v3, that kind of thing.

Big stuff delivered over more than one update - may be hard to say exactly, but are you thinking new feature might initially be limited, then extend in next release OR background stuff built in at one release, then feature 'made public' at next release? Either could work.

Kind of a development detail, but my intention was to convey that some things just take longer than 4 months and this plan doesn't imply we would never tackle things of that nature. If we do, we will just implement it over 2 releases, rather than delay an entire release to take 8 months to fit it in. We would develop it in the background, in other words.

 

[DavidJ]

I'd suggest don't come up with yet another set of numbers. We need to avoid confusion through the 'switchover'.

Maybe consider going back to using the old (internal) version number. I'm sure you'll think of something.

 

[Lew_Merrick]

My "take" on this subject is that the V9, V10, V11, & V12 system was fine. As I recall (not that I can't be wrong) the change to V20XX came about rather than have a V13 release. As I said at the time, the calendar should not be the driver it is improvements and polishing that should "drive" the update cycle.

 

[Seal1966]

I would love to see a release every four months. I would take the year out of it, and go with V20, V20.1, V20.2, Etc.

 

[Lew_Merrick]

I would love to see a release every four months. I would take the year out of it, and go with V20, V20.1, V20.2, Etc.

I will argue against setting a time table for update releases. They should come out as (A) problems are fixed or (B) "polishing" has been done. Whereas I often "suggest" things, I am not the one who has to code or test things. Deference to those who do have to code and test things should be high on our (users) list!

 

[tk1247]

I'm in favor of your "at least every 4 month" proposal for a several reasons:
1. I agree with your assessment of trying to put too much in one big "annual" release that often gets delayed, etc.
2. From the annual maintenance subscription standpoint, it would be more fair to subscribers to see several upgrades each year that contained both feature and maintenance improvements. 2019.0 took almost 17 months from 2018.0 to happen, and I saw several forum members who observed that their "annual" subscription was going to run out before 2019 came out, ask if they were going to get it. Spacing out feature/maintenance adds as you describe would IMHO demonstrate value add for rolling annual maintenance subscription holders.
3. It seems it might distribute your development workload better and help make meeting dates a bit easier.

From the version naming method standpoint, it does not matter to me which you go with, as long as, as others have put it, you are very clear what the upgrade/update includes/represents.

+1 on the comment above by DavidJ regarding keeping both the help file, as well as documentation and tutorials updated in time with the core program updates, as much as possible.

Tom

 

[JST]

4 month schedule is good. Basically makes it clear that development is active, and the program is not stagnating. Good for users, good marketing also. An excellent way to maintain interest and "keep the pot bubbling" even though your development staff is limited.

A regular schedule of updates keeps things happening, allows folks to get the new things without getting the re-up in the middle of it all as noted by others, and keeps interest going. And keeps down the disappointment if a yearly update does not have the feature someone wanted.... so they know they may not have to wait another year.

yes, the calendar ideally would not be the driver, but reality is that it needs to be..... aim for that 4 month interval, or, better, aim for 3 per year, whether one takes an extra month or not.

+200 on keeping the help and basic documentation updated.... Ideally you write the manual FIRST, and that drives the programming.... The tutorials I would update also, but if there is a crunch, make sure that any new features or large changes get new tutorials at release, and let the rest catch up as you can.

As for naming, I think you may as well let them be 2019-r1, 2019-r2, etc. that makes it pretty clear what is going on, and does not change very much from what you do now.

yes, big stuff do over 2 cycles or whatever it takes. Makes perfect sense. Some of the big things may come at the "yearly release", the rest can come at the 4 month "minor releases".

 

[HaroldL]

I like the shorter delivery time line. As for naming, it could be service packs (Sp1, Sp2, etc.) or version like JST mentioned or a dot release (2020.1, 2020.2, etc.)
And +++++ on the Help manual and an updated User Manual with some in depth explanations. Seems like in the past the Help and User manual were carbon copies.

 

[oldfox]

I never did like using the "year" number as a version number. It is extremely subject to slippage, it can cause some questioning within the
community's collective mind, (e.g. Where did Win9 go?") Just what the name is doesn't really matter. It is the perception of the user's as to
how well the "company" is doing. For years we used "R" or "V" XX.xx.xx and many of us more chronologically gifted understand and like this
numbering system. There is never a need to have a hole (i.e. Win9) in the release sequence and it is generally a question mark.

Without a more or less fixed structure, it becomes reactive as opposed to proactive. And that generally never works out well. It becomes turmoil and haphazard. I believe that, as stated by others, an annual major release is good. And ultimately we are all slave to what the suppliers of
other software, which we use, do.

I like Max's plan. And after all, we are now back to doing a lot better than back in the dark ages, (Geomagic). Thanks Max and crew.
Keep up the good work.

My $0.02

 

[albie0803]

I would like if any correction/updates to AlibreScript were posted immediately as a module update. Assuming, that is, that the python engine is, in fact, a separate module from the main drawing package.
If you're after a particular function to be added or corrected then a 3-month wait is too long if it can be fixed or implemented in a week.

Mind you, I have no idea what resources are available for script updates and additions, they may just have to wait their turn in the standard queue.

 

[Lew_Merrick]

And +++++ on the Help manual and an updated User Manual with some in depth explanations.

+++++ And a Lexicon to convert "CAD teerms" to conventional "Design/Drafting terms!" What is called a "Loft" today bears microscopically more than zero relationship to "Lofting" as taught from the early-19th century until the mid-1990's.

 

[DigiSnapMark]

While it's useful for project managers to operate from a schedule perspective, I'd prefer an organic release. If there are new exciting features, bring them out when available. On the other hand, some programs like Notepad++ push updates every week or two, which is more of a hassle than useful.

My bigger request is to fix the bugs that have been known literally for years! Supporting high res multi-monitors for instance. I've been reporting bugs here forever about this, and the promise is always... "we're working on it, it's a high priority". 2019 addressed a few of the multi-monitor bugs, but certainly not all. There are also new unrelated bugs that I reported in Beta, that weren't squashed either. PLEASE don't get in the habit of implementing features to make marketing look great, but leave fundamental bugs in place!

 

[Dave Sohlstrom]

I would suggest a change in the way you price maintenance. Mine expires end of OCT so if the next update came in 4 months from now I would miss it if I did not extend my maintenance. I'm on a fixed income and the price of maintenance at $400.00 is more than I can afford.
Now if maintenance was priced by the update and updates were quarterly and I could buy 2 additional updates at $100.00 each then I could swing that.

 

[Max]

I would suggest a change in the way you price maintenance. Mine expires end of OCT so if the next update came in 4 months from now I would miss it if I did not extend my maintenance. I'm on a fixed income and the price of maintenance at $400.00 is more than I can afford.
Now if maintenance was priced by the update and updates were quarterly and I could buy 2 additional updates at $100.00 each then I could swing that.

If you purchase your maintenance from Alibre direct, you have some options - for example we can do monthly payments instead of a one-time payment, which is perhaps easier to do.

 

[astroverted]

1. If it helps you manage the development cadence and minimize incidence of BUGS, then I'm all for it.
2. A naming convention containing either: a root designation based on the year of release (i.e. 2020.1, 2020.2...etc.) OR version numbering Major.minor (i.e. V19.0, 19.1...etc.) would be simple to understand. Simple is good, consistency is GOD.

 

[simonb65]

Simple is good, consistency is GOD.

+1

 

[bobsmodels]

I strongly support shorter release date intervals. I think every 4 months is a bit ambitious. You need to find a balance, maybe do not fix the interval but lay out bundles and determine the when based on the design teams you can afford. Have you thought of just having rolling development teams releasing one or two things when they are ready, sort of a continuous stream of releases, might be one a month.

Having myself managed huge software release packages ( on the order of 600+ engineers) pre 2000, the value of point releases was great from a customer point of view. Internally it required an increase in staff. The shorter the interval the more staff. Assuming 1 year design to release time for each release you would need at least two design teams and that would be tight. I think you need to look at your end to end time to develop a particular size product (ie how many work units required). You really cannot afford to have an individual engineer working on more than one or two releases at a time, the priorities will kill them and drive the managers to distraction. Then lay out staff assignments. Now you need too see about overlapping, that is how many simultaneous teams can you afford to run. That will dictate your interval. The teams I had were multi US locational, multi country, and we ran about three simultaneous teams. It also increases development CPU resources. Now this is all from pre 2000 methods so things may have changed and development is easier, but I doubt it. You still need to define feature requirements, fit them to an architecture, split up the development, testing etc., and manage the whole thing.

Anyway my point is, I as a customer, would really like a release every 4 months, but just miss it by even 2 - 3 weeks and I am annoyed, then as you scramble pulling resources from the other teams (a bad idea because more hands do not necessarily get an improved interval) to assist the late one you compound the problem on the next release. So then I get another disappointment.

As you can see been there done that, it took several years to get it running even close to running smoothly. Be careful, I do not want to see Alibre go belly up, I like it and cannot afford Solidworks and do not like the cloud based systems.

BTW the naming convention is the least of your issues.

Bob

 

[DavidJ]

I can see shorter intervals smaller update working in the normal way of things. I suspect that when there is a major back-end overhaul (like the HOOPS stuff for v2019, and the Visual Studio Version update before that) it may be harder to keep things going without having some duplication of effort.

I guess my point is that if there is a target of (say) release every 3 months or so - there may sometimes be 'major back-end change' that makes that difficult, or requires significant additional resource. I think if Alibre is up front about that, people will mainly understand - it's delays and non-delivery that annoy people.