Hi all,
First of all, congratulations on getting RT4 out of the door. The
Debian package is nearly ready to go pending some DFSG administrivia
(source to some included compressed JS).
I wondered whether you could let us know what your medium to long
term plans are for development cycles of RT4? For example, I notice
that you already have a 4.2 branch. When is that likely to see the
light of day and what sort of scale of change might it include?
I ask because I’m wondering whether continuing to name the Debian
packages after the major.minor number (ie request-tracker4.0) or
whether it might be time to consider a switch to request-tracker4
instead[0].
We don’t (and possibly can’t) need to know for certain, and that’s
okay, because we could still switch to request-tracker4.2 if needed, but
the likely outcome may help decide what the best course of action at
the moment is.
Thanks,
Dominic.
[0]. Not renaming the package between releases makes for a much
easier upgrade path; it’s been on the TODO for a long time to make
semi-automatic upgrades work between renamed packages, but it’s a
hairy area and I don’t have much impetus to work on this
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (198 Bytes)
Hi all,
First of all, congratulations on getting RT4 out of the door. The
Debian package is nearly ready to go pending some DFSG administrivia
(source to some included compressed JS).
I wondered whether you could let us know what your medium to long
term plans are for development cycles of RT4? For example, I notice
that you already have a 4.2 branch. When is that likely to see the
light of day and what sort of scale of change might it include?
I ask because I’m wondering whether continuing to name the Debian
packages after the major.minor number (ie request-tracker4.0) or
whether it might be time to consider a switch to request-tracker4
instead[0].
Hi Dom
We’ll publish an official policy in the next few weeks, but our plan
is to try and keep 4.0 to ‘bugfixes’ while features go to 4.2 and we
aim to release 4.2 in the fall. At that point, 4.2 becomes bugfixes
only and we start working on new features for 4.4.
If you can get a request-tracker4 packages instead of
request-tracker40/request-tracker42 it would make us all very happy.
-kevin
We’ll publish an official policy in the next few weeks, but our plan
is to try and keep 4.0 to ‘bugfixes’ while features go to 4.2 and we
aim to release 4.2 in the fall. At that point, 4.2 becomes bugfixes
only and we start working on new features for 4.4.
Okay. I still need to get clear in my head the relative trade-offs
between being able to install and maintain multiple versions at once
vs the simplicity of a single package name. Much of it probably depends
on the frequency of releases relative to Debian’s stable release cycle,
as well as your expectation for the support of older branches.
If you can get a request-tracker4 packages instead of
request-tracker40/request-tracker42 it would make us all very happy.
Could you expand on how that would particularly affect you as
upstreams?
Cheers,
Dominic.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (198 Bytes)
We’ll publish an official policy in the next few weeks, but our plan
is to try and keep 4.0 to ‘bugfixes’ while features go to 4.2 and we
aim to release 4.2 in the fall. At that point, 4.2 becomes bugfixes
only and we start working on new features for 4.4.
Okay. I still need to get clear in my head the relative trade-offs
between being able to install and maintain multiple versions at once
vs the simplicity of a single package name. Much of it probably depends
on the frequency of releases relative to Debian’s stable release cycle,
as well as your expectation for the support of older branches.
I’m not exactly sure when having 3.6 and 3.8 installed in parallel is useful.
If you can get a request-tracker4 packages instead of
request-tracker40/request-tracker42 it would make us all very happy.
Could you expand on how that would particularly affect you as
upstreams?
Because if request-tracker4 gets into a stable release, users would be
able to come up to a more recent release of RT without pulling the
patches from testing/unstable. We encountered a lot of folks
installing 3.6.7 because it was available in Debian and we’d done a
lot of work on 3.8 that they never saw.
We’d love to start getting large releases of RT out the door more than
once a year. We’re still finalizing scheduling and end-of-life plans
internally.
-kevin
[adding pkg-request-tracker-maintainers to this discussion as should
have been the case from the start; see
http://lists.bestpractical.com/pipermail/rt-devel/2011-May/011464.html
for the rest].
Okay. I still need to get clear in my head the relative trade-offs
between being able to install and maintain multiple versions at once
vs the simplicity of a single package name. Much of it probably depends
on the frequency of releases relative to Debian’s stable release cycle,
as well as your expectation for the support of older branches.
I’m not exactly sure when having 3.6 and 3.8 installed in parallel is useful.
It’s not so much that installing them together would be useful, but
that depending when new major releases from you appear relative to the
Debian release cycle, having two major versions in a stable release
could be useful. This is a reasonably common situation with a number
of complex packages in Debian, but there are obviously trade-offs to
be made.
If you can get a request-tracker4 packages instead of
request-tracker40/request-tracker42 it would make us all very happy.
Could you expand on how that would particularly affect you as
upstreams?
Because if request-tracker4 gets into a stable release, users would be
able to come up to a more recent release of RT without pulling the
patches from testing/unstable. We encountered a lot of folks
installing 3.6.7 because it was available in Debian and we’d done a
lot of work on 3.8 that they never saw.
I don’t think that the difference in naming will affect that situation
at all. There’s no simple answer to “stable contains old packages” –
that’s a fundamental part of how Debian works – but bear in mind that
backports of RT3.8 to lenny were available for much of its lifetime.
Having co-installable packages may actually be better for the
availability of a given major release in Debian, because it’s likely to
mean there are fewer compatibility issues (see below) to resolve before
being uploaded.
One thing that I didn’t really cover in my opening post about this
was the issue of API stability. Now, I realise that RT doesn’t really
have a formal, published API, and in fact sometimes extensions break
even with point releases, but having a lot (relatively) of breakage
between 4.0 and 4.2 would be another reason of having co-installable
packages, so that different versions of the extension could be
targetted at each, if needed.
Dominic.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (198 Bytes)
If you can get a request-tracker4 packages instead of
request-tracker40/request-tracker42 it would make us all very happy.
Could you expand on how that would particularly affect you as
upstreams?
It implies stable api’s and database schemas, yeah? If RT 4.0 is RT 4.2
is
RT 4.4 is RT4… I’m expecting upgrades to not cause my database to blow
up, or even change. I’m not saying my expectations are reasonably
informed
or accurate. I’m just saying that’s what I’d instinctively expect. If
I’m
wrong someone set me straight.
I accidentally sent this reply to an individual versus the list earlier.
-Rob
signature.asc (198 Bytes)
If you can get a request-tracker4 packages instead of
request-tracker40/request-tracker42 it would make us all very happy.
Could you expand on how that would particularly affect you as
upstreams?
It implies stable api’s and database schemas, yeah? If RT 4.0 is RT 4.2
is
RT 4.4 is RT4… I’m expecting upgrades to not cause my database to blow
up, or even change. I’m not saying my expectations are reasonably
informed
or accurate. I’m just saying that’s what I’d instinctively expect. If
I’m
wrong someone set me straight.
I expect Kevin et al can comment on any policies, but as far as know
there is nothing prohibiting database content or schema changes in
point releases. That said, it seems that the only schema change during
the 3.8 series was a PostgreSQL index. The database content did change
several times (in 3.8.1, 3.8.2, 3.8.3, 3.8.4, 3.8.6, 3.8.8). Note that
if you use the dbconfig-based automatic database configuration, these
changes will be automatically applied on package upgrade.
You’re right that (if past experience is anything to go by) the change
from 4.0 to 4.2 is likely to involve more invasive database changes).
At this point I’m inclined to release RT4 packages as
request-tracker4; this at least gives us either option. If anyone
thinks this is a bad idea, now would be the time to speak up.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
signature.asc (198 Bytes)
It implies stable api’s and database schemas, yeah? Â If RT 4.0 is RT 4.2 is
RT 4.4 is RT4… Â I’m expecting upgrades to not cause my database to blow
up, or even change. Â I’m not saying my expectations are reasonably informed
or accurate. Â I’m just saying that’s what I’d instinctively expect. Â If I’m
wrong someone set me straight.
We try not to change schemas within a stable release series, but reserve the
right to change if needed. You can find etc/upgrade -type f to see
what has changed in past releases.
-kevin