How much longer should we continue to maintain the 0.12.x release line?

[RjOllos]

I'm hopeful that we can have a 2-month release cycle going forward, with the next release by Jan 1st. That set of releases will include 0.12.7.

I don't have any interest in the 0.12 release line, but of course I will continue to fix issues on the branch until we have agreement that it should be dropped and 1.0.x made our LTS release. What do others have in mind, particularly the other devs?

Here is one proposal:

 - 0.12.7 / 1.0.3 / 1.1.3: Jan 2015

 - 0.12.8 / 1.0.4 / 1.2.0: March 2015

... and have 0.12.8 be the last release on the 0.12 line.

There are many tickets associated with 0.12-stable. I started going through these a month or two back. It would be good to triage these and re-target the tickets that are more appropriate for 1.0-stable, of which I suspect there are many.

http://trac.edgewall.org/milestone/next-minor-0.12.x

[Tetsuya Morimoto]

I agree with quick-release cycle plan, but 2-month cycle is very
short, so it's tough for trac-team I guess. I think it's important to
set a milestone to be reliable and include features/bug fixes many
users hope.

For me, I'm looking forward 1.2.0 including multi project feature.

thanks,
Tetsuya

> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to trac-dev+u...@googlegroups.com.
> To post to this group, send email to trac...@googlegroups.com.
> Visit this group at http://groups.google.com/group/trac-dev.
> For more options, visit https://groups.google.com/d/optout.

[Peter Suter]

On 26.10.2014 05:12, RjOllos wrote:
> I'm hopeful that we can have a 2-month release cycle going forward, with
> the next release by Jan 1st. That set of releases will include 0.12.7.

2-month release cycle would be great. It sounds very ambitious, but you
now probably know best if and how it is achievable.

I assume this means a simplified release process e.g. without
string-freeze periods? (Personally I think the faster iteration time
would more than compensate any drawbacks.)

> I don't have any interest in the 0.12 release line, but of course I will
> continue to fix issues on the branch until we have agreement that it
> should be dropped and 1.0.x made our LTS release. What do others have in
> mind, particularly the other devs?

Agreed. I also have no interest in 0.12.

> Here is one proposal:
> - 0.12.7 / 1.0.3 / 1.1.3: Jan 2015
> - 0.12.8 / 1.0.4 / 1.2.0: March 2015
>
> ... and have 0.12.8 be the last release on the 0.12 line.

Fine by me. (But I also have no problem if someone else wants to fix
more bugs on 0.12 and do more releases.)

[Remy Blank]

RjOllos wrote:
> I'm hopeful that we can have a 2-month release cycle going forward, with
> the next release by Jan 1st. That set of releases will include 0.12.7.
>
> I don't have any interest in the 0.12 release line, but of course I will
> continue to fix issues on the branch until we have agreement that it
> should be dropped and 1.0.x made our LTS release. What do others have in
> mind, particularly the other devs?

I'm not really qualifying as a dev anymore, and I tend to have a radical
view on such issues, but I would make the just-released 0.12.6 the last
release on the 0.12 branch, and only patch it for security issues.

Rationale: the dev team is small, and the time that you guys can spend
on Trac (thanks a lot, BTW!) should be spent on new features and bug
fixes, not on maintenance.

> Here is one proposal:
> - 0.12.7 / 1.0.3 / 1.1.3: Jan 2015
> - 0.12.8 / 1.0.4 / 1.2.0: March 2015
>
> ... and have 0.12.8 be the last release on the 0.12 line.
>
> There are many tickets associated with 0.12-stable. I started going
> through these a month or two back. It would be good to triage these and
> re-target the tickets that are more appropriate for 1.0-stable, of which
> I suspect there are many.
> http://trac.edgewall.org/milestone/next-minor-0.12.x
>

> --
> You received this message because you are subscribed to the Google
> Groups "Trac Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to trac-dev+u...@googlegroups.com

> <mailto:trac-dev+u...@googlegroups.com>.

> To post to this group, send email to trac...@googlegroups.com

> <mailto:trac...@googlegroups.com>.

[Dirk Stöcker]

On Sun, 26 Oct 2014, Remy Blank wrote:

> I'm not really qualifying as a dev anymore, and I tend to have a radical
> view on such issues, but I would make the just-released 0.12.6 the last
> release on the 0.12 branch, and only patch it for security issues.
>
> Rationale: the dev team is small, and the time that you guys can spend
> on Trac (thanks a lot, BTW!) should be spent on new features and bug
> fixes, not on maintenance.

Actually I'd vote for the same. Better to have progress for 1.x instead of
too much support for 0.12.x. For 0.12 only major bugs and security fixes.

I want a patch free Trac installation again. 1.0.2 cut mine down to 1
patch, but still not 0 :-)

P.S. For JOSM we have a monthly release schedule working fine. 2 months
for Trac also sounds good to me. With automated builds the workload should
be reduced. And from user side I prefer reported bugs (with patches) to be
fixed within two months and not two years.

Anyway I'm not part of Trac core and I think the most important rule is
"Who does the work decides!".

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

[Christopher Nelson]

On Sun, Oct 26, 2014 at 6:20 AM, Dirk Stöcker <tr...@dstoecker.de> wrote:
> On Sun, 26 Oct 2014, Remy Blank wrote:
>> I'm not really qualifying as a dev anymore, and I tend to have a radical
>> view on such issues, but I would make the just-released 0.12.6 the last
>> release on the 0.12 branch, and only patch it for security issues.
>>
>> Rationale: the dev team is small, and the time that you guys can spend
>> on Trac (thanks a lot, BTW!) should be spent on new features and bug
>> fixes, not on maintenance.
>
> Actually I'd vote for the same. Better to have progress for 1.x instead of
> too much support for 0.12.x. For 0.12 only major bugs and security fixes.

Me, three.

> I want a patch free Trac installation again. 1.0.2 cut mine down to 1 patch,
> but still not 0 :-)

>...

We recently jumped from 0.11.6 to 1.0.1 and got rid of a lot of our
patches. What a relief!

[Christian Boos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/26/2014 9:01 AM, Remy Blank wrote:
> RjOllos wrote:
>> I'm hopeful that we can have a 2-month release cycle going
>> forward, with the next release by Jan 1st. That set of releases
>> will include 0.12.7.
>>
>> I don't have any interest in the 0.12 release line, but of course
>> I will continue to fix issues on the branch until we have
>> agreement that it should be dropped and 1.0.x made our LTS
>> release. What do others have in mind, particularly the other
>> devs?
>
> I'm not really qualifying as a dev anymore, and I tend to have a
> radical view on such issues, but I would make the just-released
> 0.12.6 the last release on the 0.12 branch, and only patch it for
> security issues.
>
> Rationale: the dev team is small, and the time that you guys can
> spend on Trac (thanks a lot, BTW!) should be spent on new features
> and bug fixes, not on maintenance.
>
>> Here is one proposal: - 0.12.7 / 1.0.3 / 1.1.3: Jan 2015

Here's a middle ground: I basically agree with what Remy said, except
that 0.12.6 wasn't announced as being the last release. Maybe there
are still people blocked with Python 2.4(?) and hoping for a few last
bugfixes(?). We could announce that 0.12.7 will be the last "bugfix"
release for 0.12.x and if there are people who still care about this
line of development, here's their chance to bring forward their
patches! After 0.12.7, only have releases for important security fixes
(and that could still go on for a while, without much additional work).

Also, make clear that 0.11.x will no longer be updated, even for
security fixes (and remove it from TracDownload).

- -- Christian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJUTPPwAAoJENf0XkEiCfY2jm0IALaCgCzm8P5p9smm/mxMxbmp
Izq39Cndv2St3AB4gtAWCD1ldJ2mFMgxaRPa3uGgVwx4cpZm3FfyM7wy9GVzJ7D/
uu6NV6q1rDWBpvR8ogr8P/oTbkFkzwtV8/VPDj4ghI7Ws9e+h3mdZoyrlY0jv4RE
AlWpNDPhi7jz8Li7a4GfHzehX7i4lop1stAYDRDQaF2gActAXSmPQ4Ds33qYcCGs
BBpBpY87pNoM3qVK1RB0sCLyx4h+QzszqrrLSMp9Iskbd3SMFX+XeTS8RTzUZ1mG
7wPOib+5VMenTYQRta9SMwFlLxBf0PQaTcbIZ14u+5HLxuT96Mf6YGexrMWelVA=
=gE8c
-----END PGP SIGNATURE-----

[Ryan Ollos]

Having a final planned release on 0.12.x sounds like a friendly transition. How should we go about announcing this? Is the discussion in this thread along with some edits to the wiki enough, or should we post a formal message to the trac-announce channel?

[Ryan Ollos]

On Sun, Oct 26, 2014 at 12:57 AM, Peter Suter <pets...@gmail.com> wrote:

On 26.10.2014 05:12, RjOllos wrote:

I'm hopeful that we can have a 2-month release cycle going forward, with
the next release by Jan 1st. That set of releases will include 0.12.7.

2-month release cycle would be great. It sounds very ambitious, but you now probably know best if and how it is achievable.

I assume this means a simplified release process e.g. without string-freeze periods? (Personally I think the faster iteration time would more than compensate any drawbacks.)

It will probably be a bit challenging, but should be much more achievable as we tweak and script more of the release process. I think there are some small things that we can do, such as #11725, which together will make the whole process a bit easier. Even just having a smaller set of tickets will make writing the change log easier, or we can do that part as we progress through the milestone.

trac.edgewall.org/ticket/11725

[Peter Suter]

On 28.10.2014 04:37, Ryan Ollos wrote:
> It will probably be a bit challenging, but should be much more
> achievable as we tweak and script more of the release process. I think
> there are some small things that we can do, such as #11725, which
> together will make the whole process a bit easier.
>

> trac.edgewall.org/ticket/11725 <http://trac.edgewall.org/ticket/11725>

Yes, that sounds like a great idea.

> Even just having a
> smaller set of tickets will make writing the change log easier, or we
> can do that part as we progress through the milestone.

I always thought the ReleaseNotes were supposed to completely replace
the ChangeLog, just for this reason. Maybe this was not done so far
because the ReleaseNotes were considered too long and detailed? Then
this could also be reconsidered with the smaller set of tickets. Or did
I miss something?

http://trac.edgewall.org/wiki/TracDev/ReleaseNotes
http://trac.edgewall.org/wiki/ChangeLog

[Greg Troxel]

RjOllos <rjo...@gmail.com> writes:

> I don't have any interest in the 0.12 release line, but of course I will
> continue to fix issues on the branch until we have agreement that it should
> be dropped and 1.0.x made our LTS release. What do others have in mind,
> particularly the other devs?
>
> Here is one proposal:
> - 0.12.7 / 1.0.3 / 1.1.3: Jan 2015
> - 0.12.8 / 1.0.4 / 1.2.0: March 2015
>
> ... and have 0.12.8 be the last release on the 0.12 line.

From a packager and often trailing-edge user of code (but not trac):

For old branches, it's far more important to fix security bugs than
functionality. At this point anyone running 0.12 should have already
updated to 1.0 (it's been 2 years, and that gives people 6 months of
waiting to be sure it's ok and then 18 months to have updated). So
security patches are helpful to those who can't (where "can't" means
it's too hard). At some point, that becomes unreasonable.

You used the word "LTS". LTS usually refers to a commitment to have
security patches for a really long time, on the order of 5 years,
specifically for people who want security fixes and no other changes.
Moving the LTS designator every 2 years doesn't really make sense.
But, deciding to no longer have any support for 0.12 when 1.2 is
released certainly seems reasonable. It would also be reasonable to
have dropped 0.12 support after 1.0 had been released and free of real
trouble for a year. (I'm not saying it was trouble; my point is that
first you wait until it's safe to update for random users, and then a
year.)

I maintain the trac package in pkgsrc, and am generally conservative
about updating to new major versions. The question I ask myself is: is
a user who doesn't really know how to choose which version to run better
served by upgrading now, or would it in general be better for them to
wait? I updated pkgsrc to 1.0 on 2013-02-13, which is 5 months after
release. Part of that was probably me not getting around to it, but
that sort of delay feels fairly normal to me.

Overall, I would recommend treating 0.12 as closed to anything but
security fixes, more or less now.

[Christopher Nelson]

On Wed, Oct 29, 2014 at 8:59 AM, Greg Troxel <g...@ir.bbn.com> wrote:
> From a packager and often trailing-edge user of code (but not trac):
>
> For old branches, it's far more important to fix security bugs than
> functionality.

Agreed.

> At this point anyone running 0.12 should have already
> updated to 1.0 (it's been 2 years, and that gives people 6 months of

> waiting to be sure it's ok and then 18 months to have updated). ...

Speaking as someone who ran 0.11.6 until last month, I can agree
philosophically but point out that it doesn't work out that way
practically.

> ...

> Overall, I would recommend treating 0.12 as closed to anything but
> security fixes, more or less now.

I can't disagree.

[Jun Omae]

On Tue, Oct 28, 2014 at 12:36 PM, Ryan Ollos <rjo...@gmail.com> wrote:
> Having a final planned release on 0.12.x sounds like a friendly transition.

+1.

> How should we go about announcing this? Is the discussion in this thread
> along with some edits to the wiki enough, or should we post a formal message
> to the trac-announce channel?

I think we should announce string freeze on trac-dev with Cc to
translators and Transifex messages. All translators do not altogether
subscribe trac-dev/trac-announce mailing list.

--
Jun Omae <jun...@gmail.com> (大前 潤)

[RjOllos]

I'm not sure what the history is or possible future plans. It does seem useful to at least highlight some major features in the ReleaseNotes or ChangeLog, though perhaps we could reduce the level of detail and put the content in the ReleaseNotes rather than the ChangeLog. I also question whether we need to continue to maintain the ChangeLog file in the repository when it could just contain a link to the ChangeLog or ReleaseNotes on the wiki.

Also, in order to facilitate timely releases I'm going to aim to have no more than 5 or so tickets in the upcoming milestones assigned to myself at any given time. Currently I have several dozen tickets assigned to myself for the upcoming milestones and I'll be paring down this list in the coming weeks. With fewer tickets in the upcoming milestones (and therefore more tickets in the "next-stable-1.0.x" and related milestones), I expect it will be easier to wrap things up and generate a release.

[RjOllos]

I made a ticket: http://trac.edgewall.org/ticket/11827

Please post any action items I might have overlooked to the ticket. 

[RjOllos]

On Friday, October 31, 2014 11:13:05 PM UTC-7, Jun Omae wrote:

> How should we go about announcing this? Is the discussion in this thread
> along with some edits to the wiki enough, or should we post a formal message
> to the trac-announce channel?

With the proposed release date of Jan 2nd, I should take action on this soon. I could send a message similar to this one:

https://groups.google.com/forum/#!searchin/trac-dev/string$20freeze/trac-dev/7RZXueS_5jk/Y2VEXE-QDmoJ

I'm just volunteering in order to make sure the release can go according to schedule, but if anyone better suited to this task wants to send the announcement, please do.

The announcement for Transifex should then be copied here:

https://www.transifex.com/projects/p/trac/announcements/

I noticed in the Google groups message that there is a long list of users CC'ed. Those must be the translators. Is there a publicly or privately accessible list of email addresses for those translators?

I haven't looked at what's needed to import the translations from transifex.

http://trac.edgewall.org/ticket/11694#comment:36

If anyone wants to get going on that and show what's needed, I'd be happy to pitch in to help as much as I can.

[RjOllos]

From the discussion I've seen it looks like we've arrived at the conclusion that only critical issues will be fixed for Trac 0.12.7. We'll update the translations for that release and after that only security fixes will be provided.

I'm happy that we are putting the main effort towards 1.0-stable and beyond, which might result in a bit more overall momentum for the project. I will add however, that while I'm happy to not have to prepare fixes for 0.12-stable for most of the tickets that I'm working, I would have no problem with someone backporting fixes to 0.12-stable if they have a vested interested in the branch. I say this based on two things:

 1. Christian's comment about 0.11-stable (1) 

 2. Jun seems to have a vested interested in 0.12-stable (2), going so far as to make a plugin to backport fixes (3). Jun, if you'd prefer to put that effort to backporting fixes to 0.12-stable, that would be just as well to me at least. Assuming I'm the "release manager" for the next set of releases, I'm just as happy to a prepare release for the 0.12 line as well. It will be done for 0.12.7 regardless, and it's not that much extra effort to add a 0.12.8 with 1.0.4. I'm just happy to not have to backporting many fixes myself :)

(1) http://trac.edgewall.org/ticket/9602#comment:1

(2) http://trac.edgewall.org/ticket/11796#comment:7

(3) http://trac-hacks.org/wiki/TracFewFixesPlugin