Mono-D v0.5.5.5 - Huge completion refactoring/v0.5.5.6 - Bug fixes

[Alexander Bothe]

On Saturday, 28 December 2013 at 06:55:21 UTC, ilya-stromberg 
wrote:
> When I used `ppa:keks9n/monodevelop-latest` repro, the 
> MonoDevelop updated every day. So, it was alpha version. BTW, I 
> had a lot of problems with it, new 
> `ppa:ermshiperete/monodevelop` looks much better.

Although I'm rather interested in providing a good platform for 
everyone I can't keep an eye for everything. As I've also left 
Ubuntu I honestly don't care about this apt-get magic anymore. 
I'm providing my own MD distro which is working with most setups 
and that's it. If someone's willed to use other versions, I can't 
care about each platform's specific release strategies.

> I repeat, please write supported MonoDevelop version at the 
> download page. You have too many opportunities for Ubuntu: we 
> have 3 different repros and nobody knows the correct one. BTW, 
> `ppa:ermshiperete/monodevelop` contains pre-installed Mono-D, 
> so it looks like the maintainer wants to support correct 
> MonoDevelop version for Mono-D.

If I write 4.2.2 somewhere at the bottom, it can be the case that 
there are different releases called 4.2.2 - featuring broken API 
and other things.
I've been following that 'development' over the last couple of 
years - and it was deadly annoying to have broken API and 
nonsense exceptions after each rebuild.
Yes, this might be the issue with Mono-D as well, but as soon as 
I'm introducing new features it's very often the case that 
internals change - and therewith new regressions/throw-cases rise.

I'm also no test engineer who is willed to build GUI test 
infrastructures - perhaps I just could code more carefully, but 
well, even then unexpected situations will(!, I've had these 
situations often enough now) occur.

> Additional request: please use more intuitive version number, 
> see http://semver.org/ because current version scheme doesn't 
> provide any additional information.
> Please use:
> 1) 1-st digit if you need to upgrade the MonoDevelop version 
> with incompatible API changes
> 2) 2-nd digit if you have new features, code refactoring or any 
> other big code change
> 3) 3-d digit if you have only bug fixes
> It can help a lot. For example, 2 last Mono-D versions should 
> have 0.5.6.0 and 0.5.6.1 numbers.

Same stuff here: I'm using these numbers just to indicate an 
update for MD's update manager. If I could, I wouldn't even use 
those - as with all the continous integration there can be API 
changes everytime - either via Refactoring or via new feature 
introduction or even via bug fixing.
I probably would have released Mono-D v456 now if I followed 
these strict rules.

Or you have a second setup which is just dedicated for some final 
user verification.

Or you just come back in a year and check it out again - if 
Mono-D still exists then, who knows.