Hi Jacopo

If you get a chance the xui jar in guiapp is still running the 1.4 version.

Regards
Scott

On 29/04/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Ok, David I agree with you that removing hard-coded error messages
from services can be done on the trunk and not in release branch
because they can cause others issue and new bugs.
What about only to change the Italian language properties files that
can be included into the trunk and in the branch so that what can be
translated without touch the source can be done.

Thanks
Marco
Il giorno 28/apr/07, alle ore 19:30, David E. Jones ha scritto:

>
> I don't think this is a question I can answer, so opinions from
> others would be helpful.
>
> The problem is that I wouldn't consider this effort to be a bug
> fix, but rather a new feature. So, as with many many other new
> features, this should go only into the trunk and wait for the next
> release branch to get into a stable release.
>
> This is an issue we knew a long time ago would happen with probably
> many hundreds of different features even soon after the release
> branch was done. Well, now the release branch is in place and we
> just need to stay the course and make sure to maintain the purpose
> of a release branch, ie only bug fixes should go in, and no new
> features.
>
> -David
>
>
> On Apr 28, 2007, at 11:16 AM, [EMAIL PROTECTED] wrote:
>
>> Hi David,
>>
>> What did you think if I finish my old job of OFBIZ
>> internationalization before complete a stable release 4.
>> Some tasks still need to be completed like error messages of
>> services most of those are hard-coded into the java sources.
>> I think it's important to have it in a stable release because for
>> example if someone Italian people look at OFBIZ what to know if
>> the software is translated in Italian.
>> So if you are agree with me I can provide those patches to be
>> included in this release.
>>
>> Thanks
>> Marco
>>
>> Il giorno 28/apr/07, alle ore 11:10, David E. Jones ha scritto:
>>
>>>
>>> This is something we should always keep an eye on and try to keep
>>> up with, and of course has been an issue with OFBiz since the
>>> beginning 6 years ago (the OFBiz birthday is on May 13th, BTW).
>>>
>>> After doing a branch is a good time to be a little more
>>> aggressive on this, not that we shouldn't at other times, so yeah
>>> if it seems to be working fine locally then please do.
>>>
>>> I'll be working on the bsh update soon (after working through
>>> some other recent bugs/issues in the last couple of days).
>>>
>>> BTW, I finally did a review tonight of pretty much all of the
>>> outstanding issues in Jira. It took about 3 hours to sort through
>>> them and figure out which ones I personally would like to work
>>> on. There are quite a few!
>>>
>>> Anyway, yeah, onward and upward. Just in case anyone who is
>>> reading in is wondering we are working on adding even more
>>> committers, so hopefully we'll start making more progress on this
>>> backlog. Of course, even with more committers we still need more
>>> people in general reviewing and participating in Jira issues and
>>> such. So if anyone out there is wondering how to help, that is a
>>> great way! Just download and test patches, or comment on
>>> discussions, or any little thing just to get involved.
>>>
>>> I guess that's a bit off topic, but something I like to mention
>>> frequently... ;)
>>>
>>> -David
>>>
>>>
>>> On Apr 28, 2007, at 3:01 AM, Jacopo Cappellato wrote:
>>>
>>>> Now that we have a branch for the new release, what do you think
>>>> about a bit more aggressively upgrade in the trunk the external
>>>> jar files that we distribute with OFBiz?
>>>> This could cause some issues due to runtime dependencies but
>>>> maybe this is the right time to do this.
>>>> I'm ready to upgrade the commons-* jars (I'm running them in my
>>>> local box since a few days without issues), then we could move
>>>> on with other jars (like the iText jar).
>>>> We should also try to document/report runtime dependencies here
>>>> (there is a column for this):
>>>>
>>>> Jacopo
>>>
>>
>


Reply via email to