We've been in the current cycle (6.4 stable, 6.5 development) for such a long time that the question has been raised as to whether we've changed the policy.

Before attempting to answer that, let's review what the policy has been. As in politics, in the software world, people tend to divide into two camps: those who prefer "stability" and those who prefer "continuous advancements". One common response among software developers to this split is to offer a "stable" and "development" release, which we've done now for many years.

The scheme depends on the idea that the people in the "continuous advancement" camp act as willing guinea pigs, demanding, putting to use, and working out the kinks of new features, while the people in the first camp bide their time, enjoying the benefits of stability, until such point that the advantages of the new features become sufficient to overcome their aversion to change. At that point, we start the cycle over -- the development version becomes the new stable version (with a new even number) and we start a new development version (with a new odd number).

The difficulty is determining the suitable point for the change of cycle. In more commercial firms, it's driven by marketing (hyping of new features) and by revenue (charging for the upgrade). But we're not much good at the hyping, and the maintenance model eliminates the need to charge for updates. So from our perspective, there's no particular force pushing the cycle forward, and instead we've somewhat relied on the customer base demanding it. And for varying reasons that may be as much sociological, economic or even political as technical, those in the "stable" camp have not been exerting much pressure for rolling over the cycle. And in some ways, the longer one waits, the more difficult the idea of updating seems.

So, even though both sides seem to agree with the concept, neither side feels pressure to turn the crank to the next position in the cycle.

There's also the human tendency to want your cake and eat it too, which appears here in the form of stable-campers who try to negotiate to add individual pet features into the stable version, i.e. to get the benefits of advances without the pain of a major update.

The problem is exacerbated further by the fact that even though the people in the "stable" camp have theoretically similar views about the merits of stability vs. advancement, they differ greatly among themselves when it comes to deciding when it's time to update. Each time we roll over the cycle, some percentage of the people in the stable camp refuse to upgrade, leaving us in the awkward position of having multiple stable versions to support. (We still have active users on 6.0 and 6.2)

Not to mention of course that this year has seen enough disruptions and unresolved crises that both the energy level and the appetite for a big undertaking is somewhat attenuated.

All of which is to say we haven't dropped the policy -- we're just procrastinating.

But I agree, it's long overdue that we start a new cycle.

We'll try to reach out to users and developers currently on 6.4 to see if there are any major objections, and if not, I propose we shoot for the end of this year. In the meantime, feel free to air concerns, ultimatums, requests, etc. here for public discussion.

I have no issues how it is now...
Every month or so I hunt down the very latest 6.x development I can get my hands on, read the ashdev release notes between the last time and this time, test anything i think I use thats possibly changed, and all done, usually takes about half hour each time and easy to keep on top of things as changes are fresh in everyone's memory. If no issues in house after a month it can be rolled out if/when needed, I cant remember ever needing to roll back a customers ashell.

I like to get the latest and greatest, load it on my development system, and try to wait at least until that night to put it out! 😊

I'm probably not the best example on this but, what I do is:
1. always work with the very last release in my development environment
2. keep the last 20, or so, previous versions in the BIN folder, ready to replace the current one and check differences in behavior when something strange happens
3. in my customers, three things can happen:
a) if the very last release have some crucial fix, that becomes their stable release
b) if the very last release have some crucial fix for a specific customer, that customer use that one and the other customers wait for the results
c) if the very last release have minor fixes or new features, they wait for the next or next two releases until get updated

This is a model that, surely, is only compatible for my structure and dimension anyway, here is my two cents.

It seems as though Jack has been taking advice from the white-house, attempting to divide us between "Stable-campers" (almost lumped in with the flat-earthers) who only exist to benefit on the backs of the "Bleeding-edge campers" (the elite progressives), who by their own blood sweat and bugs do all the heavy lifting.

I believe this is a false premise. As the "bleeding edge" camp are by and large the ones who make the most requests and thus also benefit from these changes. Yes, eventually all can benefit, however these explorers are the ones who have the machinery in motion to fulfill their own specific needs and sometimes only beneficial to themselves requests. Thus is the penalty for being in this camp.

There has been a long standing policy that only bug fixes would be rolled back into stable releases. I think this is still fair and reasonable. I also still believe its fair and reasonable to lock down a version when you see fit. Your willingness to support multiple prior stable releases is completely a business decision on your end and thus shouldn't elicit any sympathy from the group at large.

I have been an advocate of the "stable" camp - mostly because we have hundreds of servers to maintain. We don't have the benefit of being able to keep these up to date at the same time utilizing latest and greatest features. We decide when its important to move forward with a version that benefits our specific needs. At this time we have been on 6.5 for a while. I don't grab new versions until there is a fix or feature that i need to utilize. SO yes, we like our cake and eat it too but we are in control of what version we need/want.

With that being said, if you want to create a stable version, we would probably vet that out, and update to that version. And as soon as we do that... there will be a new widget that we need and the cycle continues.

Apologies for giving the impression that I was taking sides. I will admit that it is easier to give the people in the "bleeding edge" camp (as you call them; I would prefer "continuous enhancement") camp what they want, i.e. just keep the new features coming. The stable-campers require a formal two-track release cycle, which is a lot more difficult to maintain, and requires momentous decisions to be made regarding cutoff points. And then once the jump from one stable version to the next is made, despite our best efforts to maintain compatibility, it's not unusual for there to be issues with things working differently. Which creates stress and also forces the stable-camper into being more of a bleeding-edger, at least temporarily. Even if there are zero issues with the upgrade, it becomes natural now to start playing with new features, which sometimes leads to suggestions about how the new feature could have been implemented better, or further improved. Which then creates another kind of stress trying to maintain the "rule" of only bug fixes for the stable version.

That said, the concept of a stable version, for which bugs can be fixed with little risk of introducing new behavior, remains valid and useful for some of our largest customers. So at the moment we don't have any plans to give up on it. But that isn't to say we aren't going to continue to struggle with the question of when is the right time to sink a large block of time and effort into advancing the cycle.

With that being said, why not close out the development copy after some reasonable time frame. 12 mos? 18 mos? 24 mos? otherwise there will always be 1 more feature...

Every new version has some freeze point at which it has to be the "current release". How long do you think microsoft or apple locks down an update before deploying?

If some here don't want to adhere to that model like Jorge because his customers are more one-off entities then he can exist on the bleeding edge.

At this point i want to be clear i am not advocating for either solution. There are times when i need a new feature which will require us to grab a development copy and vet it out in house and just make it our "standard" copy. So I/we are going to officially abstain from any vote in direction.

A reasonable time frame of course sounds reasonable. But in the absence of external forces (customers, marketing department, etc.) pushing it, it tends to seem arbitrary and counter-productive to force it at a certain time, just because "it's time". Ideally, we do it after a period of relative calm (which we've actually had lately, however bizarre that may be in comparison to the world outside.) So maybe it is time.

The comparison to Microsoft and Apple in some ways cuts the other way though, as I would say that both have pretty much discarded the stable/development release model in favor of semi-continuous, mandatory, mini-updates. Imagine if we adopted that model (call it SCMMU) and just pushed bundled updates out every few days, weeks or months, when we decided they were ready? (I'll spare you the need to register the obvious reply: that if we had sufficient QA to nearly eliminate the need for you to test the updates yourself, it might not be so bad.) Even then, some of the most outraged complaints we get about updates relate to changes that aren't bugs and are arguably improvements. People don't like change or may like it in theory but don't like a particular change in practice. (I will confess to hating the constant changes Microsoft makes to the Office user interface myself. And one doesn't get much sense that the big software houses feel much push-back on that front; on the contrary it seems as if it's all about showing off a new look as frequently as possible.)

Again, let me reiterate that we're not abandoning the dual-release system. We're just struggling a bit to decide when to start the next cycle. The one piece of advice I'd like to suggest to our stable-campers (or maybe it's a plea) is that you set up your in-house system to make it easy to launch both versions against the same programs and data. Once you set that up, it doesn't take much extra effort to update the development version regularly, and switch between the two versions regularly in the course of your normal development or customer support work. That way any unintended compatibility issues that creep into the development version will quickly become apparent, allowing them to be resolved efficiently. As you know, one of the most frustrating aspects of a making a major update and then discovering some obscure problem is that if the problem was actually introduced over a year ago, it often becomes extra difficult to identify and fix without secondary ripple effects. Avoiding that scenario is the whole point of the stable release, but unless you never update, in the end it can't be avoided. So it becomes a sort of "pay as you go, or face a big payment later" choice. I would strongly advocate for the pay as you go approach, meaning maintain an updated development system and run it in-house as much as possible, even while you keep your customer base on the stable release.