On 8/6/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
snip
i will dub trunk JAMES 3.0 and update next-major in JIRA to 3.0
- robert
Some issue have as fix version both next-major and trunk: in my
original idea an issue was in next-major if it was
On 8/7/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
snip
feedback from users should be very useful in deciding the best approach
Will we be able to support our users on every implementation we have in
trunk? I personally have limited knowledge in some
Stefano Bagnara schrieb:
Robert Burrell Donkin ha scritto:
On 8/3/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
My opinion is unchanged since next-major: imho we can have a release
even tomorrow, maybe we should consider whether it is better to release
another version of the handlerapi
i count
+1 robert burrell donkin
+1 Stefano Bagnara
+1 Bernd Fondermann
+1 Serge Knystautas
+1 norman [EMAIL PROTECTED]
+1 Søren Hilmer
+1 Vincenzo Gianferrari Pini
+1 Danny Angus
(all binding)
please jump in with corrections if i've miscounted otherwise, this VOTE passes
i will dub trunk
On 8/3/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Danny Angus ha scritto:
On 8/3/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
I also agree that it added confusion: I had a clear view on what
next-minor and next-major was and at that time I thought it was clear to
everyone (I'm used to
Robert Burrell Donkin ha scritto:
i count
+1 robert burrell donkin
+1 Stefano Bagnara
+1 Bernd Fondermann
+1 Serge Knystautas
+1 norman [EMAIL PROTECTED]
+1 Søren Hilmer
+1 Vincenzo Gianferrari Pini
+1 Danny Angus
(all binding)
please jump in with corrections if i've miscounted
Robert Burrell Donkin ha scritto:
On 8/3/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
My opinion is unchanged since next-major: imho we can have a release
even tomorrow, maybe we should consider whether it is better to release
another version of the handlerapi (the current trunk) or it is
On 8/2/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Danny Angus ha scritto:
I don't remember anyone suggesting the modularisation as a solution to
our problems (at least since I joined JAMES, that is before the problems
started anyway ;-) ).
I don't think anyone did, but there was an
Danny Angus ha scritto:
On 8/1/07, Søren Hilmer [EMAIL PROTECTED] wrote:
I really think this next-minor/next-major stuff has added confusion.
I agree with Soren.
I also agree that it added confusion: I had a clear view on what
next-minor and next-major was and at that time I thought it was
Danny Angus ha scritto:
On 8/3/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
I also agree that it added confusion: I had a clear view on what
next-minor and next-major was and at that time I thought it was clear to
everyone (I'm used to labels to identify software sprints). But the
facts
On 8/3/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
I also agree that it added confusion: I had a clear view on what
next-minor and next-major was and at that time I thought it was clear to
everyone (I'm used to labels to identify software sprints). But the
facts proved my believing was
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
ok. What I mean is that one question could be: is a new mailet api still
in a roadmap for 3.0 ? It was one of the main point in past (not in my
roadmap). Danny: if you are tuned what's your idea about this?
The enw API will have its own
On 8/1/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
you wanted a revolution but ended up evolving the existing code base.
architecture by stealth typically creates community issues and so is
best avoided.
...
You seems so secure about what happened and what was the problem.
There has
Danny Angus ha scritto:
On 8/1/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
You seems so secure about what happened and what was the problem.
There has never been stealth in my behaviour. NEVER: I'd like to know
how did you created such opinion (hope not talking with Noel or Danny,
but
+1
Thanks, Robert. Great post!
Bernd
On 8/1/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote:
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
snip
Robert Burrell Donkin ha scritto:
The same happened from 2.2 to 2.3 when I had to brake config.xml
compatibility so to have a better architecture in 2.3. Currently the
goal was even more ambitious than the 2.3 as we wanted to introduce
much more new things but without braking config.xml
On 8/1/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote:
this is a classic case of evolution verses revolution
you wanted a revolution but ended up evolving the existing code base.
architecture by stealth typically creates community issues and so is
best avoided.
Bernd Fondermann wrote:
Bernd Fondermann ha scritto:
Stefano Bagnara wrote:
On 8/1/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote:
this is a classic case of evolution verses revolution
you wanted a revolution but ended up evolving the existing code base.
architecture by stealth typically creates community issues
On 8/1/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
snip
Btw I think we already have much simpler tasks to be solved first, like
removing the User from the imap-api module so to not have core-library
to depend on imap-api, then we can see how other refactorings will
impact on this multi
Robert Burrell Donkin ha scritto:
On 8/1/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Btw I think we already have much simpler tasks to be solved first, like
removing the User from the imap-api module so to not have core-library
to depend on imap-api, then we can see how other refactorings
trunk has been dubbed 'next-major' for a long time now. a lot of extra
function has been added to trunk and though a full release is
definitely a long way in the future, the time seems right now to
decide that a future release from this code stream will be designated
3.0.
dubbing trunk 3.0 does
Robert Burrell Donkin ha scritto:
trunk has been dubbed 'next-major' for a long time now. a lot of extra
function has been added to trunk and though a full release is
definitely a long way in the future, the time seems right now to
decide that a future release from this code stream will be
Stefano Bagnara ha scritto:
[X] +1 Dub trunk 'JAMES 3.0'
+1 for JAMES Server 3.0 -SNAPSHOT (or -dev).
JAMES is the project name
Server is the product name
3.0 will be a final/stable release. -dev or -SNAPSHOT (I prefer the
-SNAPSHOT) is more appropriate for nightly builds/snapshots. M1
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Stefano Bagnara ha scritto:
[X] +1 Dub trunk 'JAMES 3.0'
+1 for JAMES Server 3.0 -SNAPSHOT (or -dev).
JAMES is the project name
Server is the product name
3.0 will be a final/stable release. -dev or -SNAPSHOT (I prefer the
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
trunk has been dubbed 'next-major' for a long time now. a lot of extra
function has been added to trunk and though a full release is
definitely a long way in the future, the time seems right now to
[ X] +1 Dub trunk 'JAMES 3.0'
Bernd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Robert Burrell Donkin ha scritto:
i would prefer the storage/config compatibility issue to be managed by
experimental modules. this means that people can code whatever new
features without having to wait for some future next-major to be cut.
I read this as 3.0 *will* *be* backward compatible.
On 7/31/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote:
-- 8
[x] +1 Dub trunk 'JAMES 3.0'
--
Serge Knystautas
Lokitech software . strategy . design http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
i would prefer the storage/config compatibility issue to be managed by
experimental modules. this means that people can code whatever new
features without having to wait for some future next-major to be
Robert Burrell Donkin ha scritto:
in terms of storage/configuration compatibility:
1 i don't believe that a decision needs to be taken now and would be
better taken later against a concrete proposal
2 i believe that development on most proposals could be done without
the need to break
Am Dienstag, den 31.07.2007, 10:05 + schrieb Robert Burrell Donkin:
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
trunk has been dubbed 'next-major' for a long time now. a lot of extra
function has been added to trunk and though a full release
On 7/31/07, Stefano Bagnara [EMAIL PROTECTED] wrote:
Robert Burrell Donkin ha scritto:
snip
IMHO it worth specifying that this is not the panacea because this means
that backward incompatible changes in core stuff will not be supported
unless you clone all of the modules.
that what
+1
I really think this next-minor/next-major stuff has added confusion.
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrailPhone: +45 25481225
Pilevænget 41Email: [EMAIL PROTECTED]
DK-8961 Allingåbro Web: www.widetrail.dk
On Tue, July 31, 2007 10:00, Robert Burrell Donkin wrote:
33 matches
Mail list logo
