What is the release date for Confluence 6.0 Server?

[Michael Montalbano]

My company is planning to move from Cloud to Server for both JIRA and Confluence. I see the that Cloud version for Confluence has recently moved to Version 6.0. When can we expect the server version 6 to be released so the migration will be compatible?

[Sherif Mansour · Accepted solution]

What @Nic Brough [Adaptavist] said! We're working on it. We've got a lot more to go to get it ready for Server and we will release as soon as we can. As you probably may have heard, 6.0 will contain our live / realtime editing feature which is a significant amount of work.

A version being on Cloud means it's close to ready for Server release (i.e. if 6.0-rc45 is on Cloud, you're looking at days or weeks, rather than months) but you won't get a guaranteed date until it's actually out - when it's ready.

This isn't quite correct. The moment we release a server release (e.g. 5.9 in this case) the the next Cloud release (which happen weekly) starts on the next major version e.g. 6.0. We will release to Cloud multiple times before we cut the Server 6.0 release. 

[Nic Brough -Adaptavist-]

Thanks for the clarification @Sherif Mansour I'll refer people to this answer next time it comes up. With "When it's ready" of course. (Because I really like "when it's ready")

[Michael Montalbano]

Thanks for the feedback. Being in software development myself, I fully understand and agree with "When it's ready" as an answer. However, my reason for asking the question still remains. Do we have to wait for Confluence 6 (server) before we can successfully migrate from Cloud to Server?

[bmamlin]

Eager to see the direction of live editing (even if in a buggy development state) to see how well the approach will work for open source communities. For example, will we be able to put shared meeting notes into a shared edit mode such that any authenticated user who pulls up the page starts in edit mode (à la etherpad or Google docs)? Or will there always be a hurdle (a click) before someone can edit? Trying to maintain high hopes & reasonable expectations for this game-changing feature for Confluence. :-)

[barnesy]

The Confluence team is pleased to announce that the Confluence 6.0 release candidate is now available, complete with collaborative editing. Please note that this is a development release and should NOT be installed in production. Please see the release notes for more details and to download. The final Confluence 6.0 release is not far away.

[barnesy]

The Confluence team is pleased to announce that the Confluence 6.0 release is now available, complete with collaborative editing. Please see the release notes for more details and to download.

[Christian Steindl]

Is there some news about Confluence 6.0 release? I'm migrating from cloud to server right now and unable to install Add-Ons because OD-Version is not supported on the market place. Since Dec 7, even months have gone by... 

[David]

I understand the "when it's ready" answer but by now you must have a vague idea if we're looking at another 3, 6, or 12 months, right ?

I'd hate to migrate to the latest 5.9.x only to learn that 6.0 comes out 2 weeks later...

Thanks.

[Christian Paredes]

Any timeline?

Features?

[Nic Brough -Adaptavist-]

When it's ready.  Plus what Stephen said.

[Nic Brough -Adaptavist-]

"When it's ready".  Cloud is always ahead of Server, but it's worth checking the exact version - Server won't be released until Cloud has gone through all the testing Atlassian wants to do, so you'll see some release candidates and point releases there before the actual server release.  A version being on Cloud means it's close to ready for Server release (i.e. if 6.0-rc45 is on Cloud, you're looking at days or weeks, rather than months) but you won't get a guaranteed date until it's actually out - when it's ready.

[Davin Studer]

Yesterday. 

[Panagiotis Koskeridis]

Up until recently version 6 was in beta mode, do we have an update on release date?

[Nic Brough -Adaptavist-]

I don't think you're reading the answers here properly.  Please re-read what Bill and Sherif have said.

[Christian Paredes]

I think Atlassian is not listening... What a pitty. 

[Bill Knutson]

I would say we're in agreement that announcing a dubious date pulled from some organizational nether region is pointless and possibly bordering on fraudulent. And I definitely think that providing an initial rough timeframe (I'm fine with things like "Q3" or "August") and periodically refining (and communicating) those estimates based the best available project information is a credible approach. 

Circling back to the original topic, that is what I'm finding somewhat frustrating about the Confluence Server 6.0 release. It's been seven months since 6.0 was rolled out in the cloud. I'd appreciate some general guidance, as I am unable to read the "tea leaves" in the JIRA issues reports. Again, something like "Q3" or "August" is a good place to start; it can be refined to 23-Sep-2016 22:06:39 UCT (or whatever!) as more information becomes available.

[Nic Brough -Adaptavist-]

Oh, it's definitely not about perfection, that'll never happen.  But it is about being able to say "we are as certain as we can be about this release", and dealing with those bugs that bite close to a specific deadline.  I don't think saying "when we're ready" is a licence to avoid a release for months, it's more like days or weeks.  And it's worth being open about the progress too, so that you can give rough time-frames.

The software industry is littered with big announcements and releases "before it's ready because we fixed a date", and not one of them are edifying for the organisations who have done it.

[Bill Knutson]

An axiom: If we wait for software to be perfect to release it, no software will ever be released. A corollary: The only way one never misses a commitment is if one never makes a commitment. 

I agree with you that saying "This software performs Function X" and releasing it when you know darn well Function X doesn't work at all is unethical. But that's not we're talking about here, is it? I hope not.

I'm just talking about reasonable people making informed estimates about what can be delivered in a given timeframe so other reasonable people can make informed decisions.

Part of my definition of "well-managed process" in software development means understanding (and communicating) the "brokenness" of any given software project at any point in time and being able to project out from that knowledge delivery dates. Tools like JIRA enable us to do this. Otherwise, why bother? We just code until we decide think we're done by whatever standard of "doneness" feels right to us at the time.

I honestly don't think that's what you're proposing. But I will maintain that mature development organizations can and do make reasonable estimates about scope and time of deliverables. In fact, that's the working definition of "organizational maturity" for many of us.

That being said, things happen. If there is a show-stopper bug at the last minute, then you stop the show, right? Reasonable people understand this. A target date is a target; people and organizations miss targets. There is nothing unseemingly about revising those dates to reflect the reality of emerging issues as long as the situation is communicated transparently to the stakeholders.

[Nic Brough -Adaptavist-]

I don't think it's in the slightest bit acceptable to release something broken because you've committed to a set date. 

You do get rough timings from Atlassian, you can see the release cycles and the version fixes progressing, and see what's happening in the ecosystem too to get an idea.  But releasing before it's ready is, simply put, wrong.  It's not about well-managed processes - they can't tell you that you're going to find a critical bug 4 hours before release.

[Bill Knutson]

Your point is well-taken. However, there is nothing inherently flawed with the idea of announcing release dates. There needs to be a well-managed process behind it; that's all. It is possible to do competently and it helps customers when it is.

For example, my organization has deployed a multimedia support site on Confluence Server 5.9.x. As detailed in https://jira.atlassian.com/browse/CONF-33678, MP4s autoplay when a Chrome, Firefox, or Safari user lands on the page, even when the Autoplay option in the Multimedia macro is unchecked. This is unacceptable for our users, as is demanding only the use of Internet Explorer (or Chrome with a "stop HTML5 autoplay" extension) when using our site.

The good news is the problem is fixed and has been since November of last year. The bad news is the fix is only deployed in the cloud. There is no date announced for the server availability of the fix.

What this means for me, the manager in charge of the site, is I go to monthly executive review sessions and announce that we are unable to build and deploy (on Confluence, at least) the content that is key to the project's success. I am, not unreasonably, asked to provide a target date for resolution so budgets, staffing, and expectations can be managed.

The response "when it's ready" isn't fully embraced by the executive team, to say the least.

The credibility of Atlassian (and the people in my organization who recommended their products) is compromised at the moment. We can't use the tool to do what we were told it would do and our business is impacted.

I get the "by devs for devs" ethos of Atlassian and the antipathy of coders to "management" and their pesky accountability demands. For what it's worth, I don't work in some stodgy old bureaucracy; I'm with a rapidly growing pre-IPO tech company in an exploding market segment. But even for a "we're making it up as we go along" nimble org like us, the "when it's ready" approach is risky and frustrating. It negatively impacts projects and careers. At little transparency would go a long way in setting things right.

[Nic Brough -Adaptavist-]

I prefer it to releasing broken software just to meet an arbitrary date, often decided by people unqualified to do so.

[Bill Knutson]

What an interesting software release model Atlassian has... 

[Nic Brough -Adaptavist-]

Still "when it's ready", although some Cloud users are experiencing it.

[Bill Knutson]

Reviving this topic to see if there is an update seven months after the original question. Thanks.

[Stephen Deutsch]

Also, Cloud releases automatically jump up to the next version number once the server version has been released.  For example, when 5.8 was released, the Cloud version was set at 5.9.XXX and single features were added until a full server release was ready, and then it jumped to 6.0.  In that way, you can consider the cloud version 5.9+ rather than a full 6.0 release 

[Andrea Carl]

Collaborative Editing (part of Confluence 6.0) is in BETA and is rolled out to some Cloud instances, not all.