From bcpierce at cis.upenn.edu  Mon Oct 23 11:14:15 2017
From: bcpierce at cis.upenn.edu (Benjamin C. Pierce)
Date: Mon, 23 Oct 2017 11:14:15 -0400
Subject: [Unison-hackers] Debian stretch and Unison release
In-Reply-To: <a54cd9e9-2745-320e-d557-0adf61726f20@nachtgeist.net>
References: <56E40D71.5030204@nachtgeist.net>
 <F673088D-CB43-496F-BE28-7C79A3D991E2@cis.upenn.edu>
 <a54cd9e9-2745-320e-d557-0adf61726f20@nachtgeist.net>
Message-ID: <4BB510D5-E3BA-4F40-BAD4-9CBD848BC5AC@cis.upenn.edu>

Sigh.  Apologies for the (very) long delay in responding.  We have a baby (well, now toddler) in the house, and I?m afraid I?ve neglected Unison a bit in the meantime.  

However, I?ve been tidying things up over the past few weeks and am now nearly ready for a new release incorporating a bunch of (mostly minor) changes from the past couple of years.  My plan / aspiration is to put out a new beta version in the next few days and promote it to the main version a few weeks after that.  Just FYI.

The version compatibility issue remains.  I don?t know if Debian has a good way to do this, but it might be worth distributing both 2.48 and the new version (with different executable names) together.  

Best,

    - Benjamin



> On Sep 9, 2016, at 3:41 PM, Daniel Reichelt <nl at nachtgeist.net> wrote:
> 
> Hi Benjamin,
> 
> time flies, summer's almost over... Any news on this topic?
> 
> Debian's timetable has not changed (yet ;-) )
> 
> Thanks
> Daniel
> 
> 
> 
> On 03/17/2016 02:27 AM, Benjamin C. Pierce wrote:
>> Hi Daniel,
>> 
>> 2.48 is the latest stable release.  The development trunk is at 2.49, with no huge changes but a few things that would probably be nice to push out into the world (e.g., a preference to treat whole directories atomically).
>> 
>> We should probably plan a beta-release over the summer and push it to stable in the fall.  The only downside, of course, is that 2.49 will be incompatible with 2.48.  (In the longer run, this is something we should really consider fixing.  It would not be trivial, since the assumption that both sides have the same sets of preferences is built into the code pretty deeply, but perhaps there is something simple one could do that would work pretty well ? e.g., perhaps some preferences could be marked as affecting only the client, not the server, and differences in these would not cause version incompatibility.)
>> 
>> Best,
>> 
>>   - Benjamin
>> 
>> 
>>> On Mar 12, 2016, at 7:37 AM, Daniel Reichelt <nl at nachtgeist.net> wrote:
>>> 
>>> (Sorry for double-posting, I confused the -hackers ML address)
>>> 
>>> 
>>> Hi Benjamin, hi St?phane,
>>> 
>>> plenty of time to go, but I was wondering what your plans are for the
>>> next Unison release. I'm asking because I'd love to see a current
>>> version being included in the next Debian stable release.
>>> 
>>> 
>>> The schedule according to [1] is:
>>> 
>>> [2016-Nov-05] Transition freeze
>>> [2017-Jan-05] Soft freeze (no new packages, no re-entry, normal migrations)
>>> [2017-Feb-05] Full freeze
>>> 
>>> 
>>> 
>>> Thanks
>>> Daniel
>>> 
>>> 
>>> [1] https://release.debian.org/
>>> _______________________________________________
>>> Unison-hackers mailing list
>>> Unison-hackers at lists.seas.upenn.edu
>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>> 
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>> 
> 
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers