If fix for 2) will break the backwards-compatibility 1) might do that as well and be submitted together.
Now 2) was a long overdue problem, I don’t think there is any reason even to try make changes backwards-compatible, because it was broken in the first place. > On Dec 14, 2015, at 11:16, Steven Jacobs <[email protected]> wrote: > > It's a new attribute, but it's a closed field, which means it isn't > backwards compatible. > Steven > > On Mon, Dec 14, 2015 at 11:13 AM, Ian Maxon <[email protected]> wrote: > >> For 1), I guess the question is whether it would be a backwards >> compatible change. Since it's just a new attribute (right?...), and it >> is also sort of a new feature rather than a fix for something that was >> critically broken, I would tend toward putting it on master. If it's >> not backwards compatible though maybe it needs more careful >> consideration. >> >> -Ian >> >> On Mon, Dec 14, 2015 at 10:12 AM, Steven Jacobs <[email protected]> wrote: >>> Hi all, >>> I'm implementing a change so that datasets can use datatypes from >> alternate >>> data verses (previously the type and set had to be from the same >>> dataverse). Unfortunately this means another change for Dataset Metadata >>> (which will now store the dataverse for its type). >>> >>> As such, I had a couple of questions: >>> >>> 1) Should this change be thrown into the release branch, as it is another >>> Metadata change? >>> >>> 2) In implementing this change, I've been looking at the Metadata >> secondary >>> indexes. I had a discussion with Ildar, and it seems the thread on >> Metadata >>> secondary indexes being "hacked" has been lost. Is this also something >> that >>> should get into the release? Is there anyone currently looking at it? >>> >>> Steven >> Best regards, Ildar
