Tagging current trunk before big merge

[Antranig Basman]

Shortly a large pull request will be merged to Infusion trunk which 
clears out a large number of obsolete framework features. This marks a 
"point of no return" with respect to maintaining compatibility with code 
written against the Infusion 1.x framework - although our components 
written against the new framework will maintain their API contracts 
unchanged.

The pull request is at 
https://github.com/fluid-project/infusion/pull/591 and a list of the 
framework changes is basically equivalent to the one at 
http://docs.fluidproject.org/infusion/development/DeprecationsIn1_5.html 
. After this merge, the framework's API will be very much closer to the 
one we will deliver for the Infusion 2.0 release than the still 
basically 1.x-compatible version currently in trunk.

In fluid-work yesterday we were having a conversation about what we 
should name the tag we make to represent the current state of trunk.

https://botbot.me/freenode/fluid-work/2015-06-16/?msg=41990122&page=1

We talked over various possibilities involving 1.6 or 1.9 version 
numbers, but we considered that given we had not done any of the testing 
required for a full release and would probably never produce a full 
release based on this revision, that the use of such a specific version 
number would be misleading.

The current proposal is to tag current trunk with a meaningful string 
that clearly doesn't correspond to a release number, for example, 
"1.x-last" and then after the merge to move trunk to a semver-compatible 
release number of "2.0.0-alpha.1". This would become the real release 
number of the first release we made from trunk subsequently, which would 
then be bumped up to "2.0.0-alpha.2" etc.

If anyone would like to make a further proposal, please could you read 
up in the IRC transcript above and then followup to this thread - cheers

Antranig