My maintenance ends on December 25th. And I'm not going to continue it, I'm slowly finishing my professional activity. Now I have installed V24. If in the new year there are versions V24.1 V24.2… that will correct V24 errors, will I be able to install them despite the lack of maintenance?
Maintenance and Alibre V24 and V24.1 V24.2 ... software versions?
- Thread starter ROTTER
- Start date
simonb65
Alibre Super User
Technically no, but as @bigseb says, contact Alibre support.
This is one reason that I personally believe maintenance should be paid for an 'upgrade to a major version' and any subsequent bug fix releases that relate directly to that major version come as part of that upgrade ... rather than just the current arbitrary annual date driven thing that for many user must be a tough call as it may never be in sync with releases. But I'm sure speaking to Alibre will the best approach in your case.
This actually depends.
There have been many instances (quite a few actually) where we release bug-fix only releases after a major release and end up "giving" it to people who are not on maintenance. Each release has a date associated with it - if your maintenance expires before a release's date, you can't run it.
However, we can choose whatever date we want. For these bug-fix releases where something nasty is being addressed typically without new features, we almost always pre-date the release to be the same date as the major release. So for example, we released v24 on Dec. 6. Let's say we found some really big issues and had to make a service pack. Often, we would release 24 SP1 with the same date as v24, basically meaning that "if you can get v24, you can get v24SP1".
It's a judgement call we make on each release. If there are truly things that are workflow blocking or so ugly that we believe no one should have to put up with it, we will make the decision to predate the service pack to the original date, thereby giving it to everyone regardless of whether they are lapsed.
We don't do it every time - often times there are no such super nasty bugs to fix, and a service pack may be 3 minor bugfixes and a new feature. In that case, we would not predate it.
Our policy therefore is that yes you must be on maintenance to get bugfixes, but we very frequently go against that policy in favor of the customer to deliver bugfixes that are sufficiently critical regardless of maintenance status.
There are a lot of viewpoints on this. Depending on the type of software, this might make sense, especially when support burdens are low for a product. For our product, support burdens can be high, depending on who you are and how much you know and how much you're willing to tinker with things. If we were to allow discreet upgrades, the pricing would become a lot more complicated. Also, if we have 4 releases in a year, to stay up to date you have to interact with us 4 times now, with 4 separate purchases. It turns into a huge hassle. You would also have to buy support separately. Many people on this forum might be ok with that, but everyone here should keep in mind that this forum represents a very small percentage of our customers. If we were to go this route, a lot of our business customers would just ask why we have quadrupled the amount of purchase orders they have to generate just to stay up to date.
There is no solution that is optimal for everyone all the time, but this solution is optimal for most people most of the time. It's easy to understand, all-inclusive, infrequent to purchase, optional, and for the majority of customers is priced in such a way that is not a huge burden. We feel that is a reasonable sweet spot.
There have been many instances (quite a few actually) where we release bug-fix only releases after a major release and end up "giving" it to people who are not on maintenance. Each release has a date associated with it - if your maintenance expires before a release's date, you can't run it.
However, we can choose whatever date we want. For these bug-fix releases where something nasty is being addressed typically without new features, we almost always pre-date the release to be the same date as the major release. So for example, we released v24 on Dec. 6. Let's say we found some really big issues and had to make a service pack. Often, we would release 24 SP1 with the same date as v24, basically meaning that "if you can get v24, you can get v24SP1".
It's a judgement call we make on each release. If there are truly things that are workflow blocking or so ugly that we believe no one should have to put up with it, we will make the decision to predate the service pack to the original date, thereby giving it to everyone regardless of whether they are lapsed.
We don't do it every time - often times there are no such super nasty bugs to fix, and a service pack may be 3 minor bugfixes and a new feature. In that case, we would not predate it.
Our policy therefore is that yes you must be on maintenance to get bugfixes, but we very frequently go against that policy in favor of the customer to deliver bugfixes that are sufficiently critical regardless of maintenance status.
There are a lot of viewpoints on this. Depending on the type of software, this might make sense, especially when support burdens are low for a product. For our product, support burdens can be high, depending on who you are and how much you know and how much you're willing to tinker with things. If we were to allow discreet upgrades, the pricing would become a lot more complicated. Also, if we have 4 releases in a year, to stay up to date you have to interact with us 4 times now, with 4 separate purchases. It turns into a huge hassle. You would also have to buy support separately. Many people on this forum might be ok with that, but everyone here should keep in mind that this forum represents a very small percentage of our customers. If we were to go this route, a lot of our business customers would just ask why we have quadrupled the amount of purchase orders they have to generate just to stay up to date.
There is no solution that is optimal for everyone all the time, but this solution is optimal for most people most of the time. It's easy to understand, all-inclusive, infrequent to purchase, optional, and for the majority of customers is priced in such a way that is not a huge burden. We feel that is a reasonable sweet spot.