[request-tracker-maintainers] 4.2?

[Matt Zagrabelny]

On Wed, Jan 1, 2014 at 10:58 AM, Dominic Hargreaves <dom at earth.li> wrote:
> [fixing quoting]
>
>> On Fri, Nov 29, 2013 at 3:12 PM, Kai Storbeck <kai at xs4all.nl> wrote:
>> > On 11/11/13 00:55, Dominic Hargreaves wrote:
>> >> On Sat, Nov 09, 2013 at 08:48:32PM -0600, Matt Zagrabelny wrote:
>> >>> Is there an ETA for packaging 4.2?
>> >>
>> >> I started work on it but I am unlikely to be able to get it to a point
>> >> of release this side of Christmas owing to other commitments.
>> >
>> > Hello,
>> >
>> >
>> >> If anyone would like to pick up from where I currently am let me know
>> >> and I can push my work in progress and give some idea of the things that
>> >> need doing.
>> >
>> > I might be able to help with a few things. I'm interested to know what
>> > needs to be done.
>
> On Mon, Dec 02, 2013 at 02:04:44PM -0600, Matt Zagrabelny wrote:
>> I'd be interested in looking at the packaging too, if it isn't too much trouble.
>
> Hi all,
>
> Sorry about going silent again - I became inundated with other tasks
> during the last few months.
>
> I am just about to upload RT 4.0.18, and should be able to start on 4.2
> quite soon. I need to go back and look at the early work I did, and
> probably redo it on top of 4.0.18 and with 4.2.1, then I should be able
> to get together some issues to be looked at.
>
> The big question in my mind is about whether we need to rename the
> package to request-tracker4.2. I'd prefer not to because it's more
> work both for the package maintainer and for users, but there are couple
> of reasons for doing so:
>
> * API incompatibilty for extensions? Need to check upstream
> * Allow coinstallability for testing upgrades (not a particularly
>   compelling reason; testing should probably be done on another host
>   anyway)
> * Giving the users the choice of 4.0 or 4.2 whilst both are maintained
>   upstream. This would mean that RT 4.2 could hit unstable sooner.
>
> What do others think?

Another reason to maintain separate packages is historical precedence.

I don't think there is substantial amount of extra work for users with
a new package; do you? How much more work is it for the maintainers?

Cheers,

-mz