13 Apr
2012
13 Apr
'12
5:43 a.m.
On Fri, Apr 13, 2012 at 5:20 AM, Darrell Anderson
<humanreadable(a)yahoo.com>wrote;wrote:
AFAIK, using 3.5.13.1 may be better if some script needs to check version
numbers, though this would certainly be more aptly versioned as 3.5.14.
Seeing R14 using 3.6.0 would also be more apt, IMHO.
I get the breaking with KDE legacy but it probably isn't practical to take
it that far. It seems that non-debian package systems would be happier to
see sequential and number only versioning than what has been proposed.
(though I imagine upgrading from kde to tde will lead to whole new
packages, appending letters to the version number seems a bad idea
nonetheless).
Best regards,
Tiago
At the meeting
we discussed that would be a good release
official update for 3.5.13 soon. In connection with the fact that 1 May
it
be just half a year since the release of 3.5.13,
it occurred to me that
it
could be a nice term for the release official
updates.
Therefore I would like to discuss with you:
__1__
Is this term too soon?
This time is as good as any. There are a slew of build and usability
issues to resolve before R14 comes close for consideration for release.
Can it be manageable?
Sure.
Which patches to wait?
I uploaded a bunch of patches that fix HTML help page installations.
Everything now installs in the same location. I'm unsure of a good strategy
to back port them all.
I uploaded a slew of patches that fix numerous problems with kipi-plugins,
digikam, and gwenview.
In that latter effort I discovered more inadvertent "TQ" conversions that
likely cause occasional breakage.
Already have poised:
+ patch to close #372
The patch seems to have resolved the problem here.
+ other patches from #675
Fixing the starttde script likely is an ongoing project. I would just
backport every time there is an update.
+ workaround for #922
Every several days I look into this hoping I'll notice something
different. Thus far no luck.
+ waiting for a patch for #258
Calvin said Friday.
+ considering revert patch for #394
I haven't been having any problems since reverting the patch. I'm running
GIT, however, and not 3.5.13.
I would like (but want to wait?)
+ fix SAK. Does anyone work on it? Or temporarily turn it off?
I haven't noticed anybody addressing the issues. SAK can be disabled two
ways: through KControl, and with the build configuraton.
+ find a solution for #812
No experience or testing here.
+ find a solution for #744, #615
Recently in this list we discussed these svg failures. Would be nice if
they could be resolved for your release. Some of the svgz background images
were duplicated as png images and I pushed those all to GIT recently.
__2__
Giving an update the new version number?
Apply here mentioned a few times R13.1 (or R13.1.0)?
Release as 3.5.13.1 or 3.5.13a. Otherwise many users will get confused.
The "R14" versioning system should be saved for when R14 is releases. Press
releases will address why we changed the release version scheme.
I hope this helps!
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting