[Xfce-i18n] Fw: Re: ANNOUNCE: xfce4-weather-plugin 0.8.1 released (Harald Judt)
h.judt at gmx.at
Tue Aug 7 18:49:35 CEST 2012
Am 07.08.2012 14:56, schrieb Raphael Groner:
> Am Tue, 07 Aug 2012 14:07:15 +0200
> schrieb Harald Judt <h.judt at gmx.at>:
>> Looking at the git repository, that has also been the case in the
>> past, e.g. many languages have been added/updated a short time after
>> 0.7.4 has been released. Besides, how should I know on which
>> translations to wait for (and how long) before doing the release? Is
>> there any standard procedure? Of course I can write a mail to i18n
>> that a release is going to happen in a few days if that is what you
I think that's a bit too heavy for this plugin. I'd rather keep it
simple and traditional, like the previous releases.
>> As the plugin is still very much work-in-progress, I plan to do
>> releases more often or at least stick to the current frequency,
>> because in the current state of development quite a lot of bug fixes
>> will be necessary, and I guess it's no fun for package maintainers to
>> play catch-up or back-port patches. I guess distributions who prefer
>> more stable packages will delay updates a bit longer anyway.
> Maybe think about another version then. Please define what the 1 in
> 0.8.1 means exactly. Should packagers then care about x+1 to version
The current scheme does not follow any specific conventions. Have there
been any in the past? Roughly, y signifies the branch (0.7.x used old
provider, 0.8.x have a new one), but x does not carry any specific
meaning. At the moment, with every release I try to fix the bugs of the
current version and add a single new feature to it.
>> Another reason is that more people will be able to test new features
>> and report problems or share their opinions on the way things are
>> implemented. It could mean a lot more work if that happens later on.
>> Most people will not want to compile their own package from git, so
>> the only way to get it tested is to release new packages. (Not that I
>> don't do my own tests before each release, but there may be bugs I
>> cannot reproduce).
> Don't try to kid distributions and put the workload on the individual
> maintainers and all the users with nervous updates behaviour.
That is not my intention. But if you look at the git log, you will see
that there have already been many changes between the two 0.8 releases.
More changes means things are more likely to break. Before I do a
release, I test its functionality so ensure everything works on my
system. Whether it breaks on another system, I will not be able to tell
before it happens ;-)
That way I can also tell more easily which feature or change it might be
that causes the problem. If I stuff everything into one big release,
>> To conclude, even if some version has not been translated by the time
>> I do the release, users should not have to wait very long for an
>> updated version in their language.
> Well, again. This is the job of a maintainer. He would always be able
> to get a newer po file from Transifex. Though, that should not change
> anything about a (short) string freeze phase before an official new
> Translators need time to detect the need and think about new
> translations. I don't look into git or Transifex every day. A short
> notification mail to xfce-i18n should ease our job a lot, yeah.
I will do so next time, see the other mail I sent.
>> Please define "lightweight". It is meant primarily as a replacement
>> for the scrollbox which users will be able to hide in a future
>> version to save valuable space in the panel (feature request). You're
>> welcome to participate and state ideas for improvements. The more
>> precise, the better ;-)
> That's offtopic here for i18n. Maybe that should go to Xfce marketing.
No, I think you misunderstood. It's nothing philosophical about Xfce or
marketing stuff, but you should be more specific about what you consider
"lightweight" in regard to the tooltip text.
`Experience is the best teacher.'
More information about the Xfce-i18n