On Jun 7, 2012, at 3:06 PM, Sean P. DeNigris wrote:
Marcus Denker-4 wrote
so we should really limit us a bit. ...
Absolutely, that list is very reasonable. I'm thinking specifically of annoyances introduced in the last version or two (e.g. in 1.3 the "DebugIt" shortcut is broken, and was working in 1.2). These are contained and frustrating, but may not be showstoppers in the way that I think of that word.
Is there a fix?
I think this is a really important topic because we don't want to give our users, esp. new and business ones, the feeling that they are immediately unsupported on release. That's why I was especially excited about the new release policy which specifies two bug fix releases to the currently released version over the first year.
Yes, but bug fix releases don't make the actual fixes happen automatically.
Marcus Denker-4 wrote
The best thing is to just do it.
Let me be more specific. What I meant by "how", is technically what do I do with a slice from 2.0 in 1.4? For example, let's say SLICE-Issue-5871-FileReferencegtgtrenameTo-should-assume-same-folder-SeanDeNigris.1 gets integrated into 2.0. Several versions have passed in both contained MC packages from 1.4. In this case, I looked at all the changes and they're comment fixes and other benign items, but... if there were also incompatible changes, how would I get just the relevant ones into 1.4.
I'm looking for some code /like/ this - given FileSystem-Core-SeanDeNigris.12, either merge or make a changeset of just the changes between it and its immediate ancestor (i.e. just the fix).
You ask the author to re-do the fix in 1.4. Yes, this is a lot of work. That is why it just can't be done with everything. Marcus -- Marcus Denker -- http://marcusdenker.de