Hi,

Am 07.08.2012 14:56, schrieb Raphael Groner:
Am Tue, 07 Aug 2012 14:07:15 +0200
schrieb Harald Judt <h.j...@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
want.


http://www.xfce.org/about/releasemodel

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
z.y.x?

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, good luck!

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
release.

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.

Harald

--
`Experience is the best teacher.'
_______________________________________________
Xfce-i18n mailing list
Xfce-i18n@xfce.org
https://mail.xfce.org/mailman/listinfo/xfce-i18n

Reply via email to