Re: [cross-project-issues-dev] New components in Mars.1 (was Re: Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)
We changed the name to Mars.1 to match semantic versioning. It's a minor release on the Mars major release. Again, we really should be communicating that more clearly.
While the SR's of the past were stable, it also meant we could only introduce new functionality once a year. The industry around us is moving much faster than that and if we want to keep up and regain our leadership position we need to be faster than that. It may compromise quality a little but in the big picture we'll satisfy more users and adopters. And if we could ever get Check for Updates working properly, this wouldn't have been such a big issue.
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of Ed Willink [ed@xxxxxxxxxxxxx]
Sent: Wednesday, September 23, 2015 12:53 PM
Subject: [cross-project-issues-dev] New components in Mars.1 (was Re: Eclipse Mars 1 RC4 issue with Buildship / workspace prompt)
I was aware that 'maintenance' rules had been relaxed for Mars.1 rather
than Mars SR1 but I had no idea that it had gone so far as to allow
radically new configuration breaking contributions.
Although I no longer wear an industrial hat, I still have some
sympathies with industrial requirements.
Software version x.0 is always a bit exciting, so where stability is
required, it is prudent to wait for x.1 or equivalent (e.g. for those
who can remember RSX-11M, even releases were exciting, odd releases were
At the root of this industrial practice is a very high probability that
x.1 will be better than x.0.
When we had strict rules about SR1 and SR2, we had this very high
probability of relative improvement.
It seems that the rules have been relaxed so far that there is no reason
to expect that Mars.1 is either better or worse than Mars with respect
to existing use cases, so why would an industrial user choose Mars.1
rather than Mars? We just have three times as many configurations in
longer term usage, with no change permitted for fear of changed problems.
Why use clumsy confusing names such as "Mars.1"? Why not be honest and
admit that Mars.1 is a new release and give it a new name? Why not be
useful and provide credible maintenance releases for industrial users?
What we are currently doing seems to violate some of the principles of
the Simultaneous Release. It is there to avoid anarchy. Post Mars.1 we
will find rumor-based usage instructions such as:
Make sure you pick up EGIT from Mars.1
Make sure you do not pick Buildship
Nobody will know what they're doing and as committers we will have much
greater difficulty discovering user's configurations.
On 23/09/2015 14:39, Doug Schaefer wrote:
>> [I'm not clear why a new product is a problem with a 'maintenance'
>> release; I guess I've become too accustomed to traditional Eclipse
> Or you missed the memo that these aren¹t maintenance releases anymore.
> Another sign we really need to improve our communication around this.
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit