You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2007/07/31 10:00:28 UTC
[VOTE] next-major from trunk will be 3.0
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 imply that if the 2.x code base requires a new
major release then this will take the 4.0 designation. i have no
problem with that contingency.
here's my +1
i'll tally this vote no earlier than friday the 3rd of August 1200GMT
- robert
-- 8< ----------------------------------------------------
[ ] +1 Dub trunk 'JAMES 3.0'
[ ] +0 Sounds reasonable
[ ] -0 Sounds unreasonable
[ ] -1 Find another name
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
+1
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus ha scritto:
> On 8/3/07, Stefano Bagnara <ap...@bago.org> 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 wrong.
>
> I think that was the problem, not that it was a bad idea, but that we
> didn't all have the same understanding. We use labels in this way at
> work too, to great effect, somehow it just didn't catch on here.
FWIW, even now that we have 3.0 instead of next-major, I don't have an
understanding of people preferences/ideas about the future of JAMES. Not
that my understanding is important now, but I hope someone will better
collect such moods/opinions.
It "seems" we now agree we need a 3.0M1, this would be already a great
step: I really hope to see a 3.0M1 out there, soon!
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 better to
release 3.0M1 using the 2.3.1 handlerapi, or it is better to release one
of the experimental handlerapi.
I'm not a fan of the current handlerapi as I think it introduce
incompatibilities with the experimental 2.3.x support and it does not
provide a sufficient platform for the future (so I expect to see further
changes there sooner or later), but for the major goal of a release I'd
sacrifice almost anything, so I'm fine with any code will be there.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Danny Angus <da...@apache.org>.
On 8/3/07, Stefano Bagnara <ap...@bago.org> 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 wrong.
I think that was the problem, not that it was a bad idea, but that we
didn't all have the same understanding. We use labels in this way at
work too, to great effect, somehow it just didn't catch on here.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus ha scritto:
> On 8/1/07, Søren Hilmer <sh...@widetrail.dk> 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 clear to
everyone (I'm used to labels to identify software sprints). But the
facts proved my believing was wrong.
I still don't know what could have been a better approach to the missing
agreement on the numbers.
Btw this vote by Robert could have been started by anyone, any day in
the past: we can't tell if the result of the vote 8 months ago could
have been the same, but I hope everyone learned a lesson from this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Danny Angus <da...@apache.org>.
Phew two hours to go! :)
+1 Dub trunk 'JAMES 3.0'
On 8/1/07, Søren Hilmer <sh...@widetrail.dk> wrote:
> I really think this next-minor/next-major stuff has added confusion.
I agree with Soren.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Søren Hilmer <sh...@widetrail.dk>.
+1
I really think this next-minor/next-major stuff has added confusion.
--
Søren Hilmer, M.Sc., M.Crypt.
wideTrail Phone: +45 25481225
Pilevænget 41 Email: sh@widetrail.dk
DK-8961 Allingåbro Web: www.widetrail.dk
On Tue, July 31, 2007 10:00, Robert Burrell Donkin wrote:
> 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 imply that if the 2.x code base requires a new
> major release then this will take the 4.0 designation. i have no
> problem with that contingency.
>
> here's my +1
>
> i'll tally this vote no earlier than friday the 3rd of August 1200GMT
>
> - robert
>
> -- 8< ----------------------------------------------------
> [ ] +1 Dub trunk 'JAMES 3.0'
> [ ] +0 Sounds reasonable
> [ ] -0 Sounds unreasonable
> [ ] -1 Find another name
> ----------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [RESULT] [VOTE] next-major from trunk will be 3.0
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> i count
>
> +1 robert burrell donkin
> +1 Stefano Bagnara
> +1 Bernd Fondermann
> +1 Serge Knystautas
> +1 norman <no...@apache.org>
> +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 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 targeted to that
release otherwise it was in trunk. Now that you will rename next-major
to 3.0 what's the plan on how to use the fix versions?
Should issues better be assigned to "3.0 AND Trunk" versions or "3.0 OR
Trunk versions"?
Trunk was something like the "unscheduled" but more likely to be
accepted sooner or later in the codebase.
Will you create a "3.0M1" version or a "3.0" or both? I'm used to use
JIRA as a scheduling tool, too, but I'm not sure I understood how others
developers intended the usage of JIRA.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[RESULT] [VOTE] next-major from trunk will be 3.0
Posted by Robert Burrell Donkin <ro...@gmail.com>.
i count
+1 robert burrell donkin
+1 Stefano Bagnara
+1 Bernd Fondermann
+1 Serge Knystautas
+1 norman <no...@apache.org>
+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 JAMES 3.0 and update next-major in JIRA to 3.0
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by norman <no...@apache.org>.
Am Dienstag, den 31.07.2007, 10:05 +0000 schrieb Robert Burrell Donkin:
> On 7/31/07, Stefano Bagnara <ap...@bago.org> 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
> > > decide that a future release from this code stream will be designated
> > > 3.0.
> >
> > This is not correct,
>
> (IMHO correct but incomplete: the artifacts created by the trunk build
> are named next-major)
>
> > let me explain:
> > next-major was the name assigned to a tentative release and branching
> > trunk was in the plan for next-major. The difference between trunk and
> > next-major was in the planning/scheduling and was present in JIRA when
> > we used this labels to discuss what was going to land next-major
> > (storage/config compatible) and what would have had to wait the
> > following (storage/config incompatible).
>
> 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.
This sound good to me. But what's about core changes ? How the changes
will be handled there ? Do we need to "copy" and paste core stuff ?
I think we should think about if we really want todo this... Maybe throw
away the compatiblity now is not a bad action. But if we do so we should
take care todo a code design now. I think the worst whould be to change
everything again in next release after 3.0.
Just my 2 cent
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Stefano Bagnara <ap...@bago.org>.
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 storage/configuration compatibility. this may mean
> forking some modules and decoupling more parts of the system.
> 3 i would prefer to see 3.0 storage/configuration compatible by
> default but users able to choose new, incompatible solutions
> 4 i would prefer to see more development on trunk and less on branches
I agree on #1, #3 and #4. I'm not on the same line about #2, but given
we agree on #1 we can ignore this.
>> 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 you mean by core. an example would be useful.
There are old refactorings that have been delayed forever because of
introduced incompatibilities.
- One of them is mailet api changes: when you change the mailet api you
probably need to change a lot of code in james.
- One is the Message/Envelope change and the refactoring of mail/spool
repositories interfaces: again there is many code bound to this interfaces.
- One is complete DNS support (requires changes in mailet api, in
smtpserver, in the spoolmanager and in the remote delivery) [trivia: I
joined JAMES mainly to add DSN support to it].
- probably there are many more I don't remember now.
Btw, as you pointed out, maybe I'm too much worried about this as it
seems as no one have this issues in the roadmap anymore.
> the next step in the modularisation needs to be factoring out features
> from the core into API, library and functions. with a little bit of
> luck and some refactoring, i hope that core module can be eliminated.
+1
> dubbing trunk 3.0 (rather than next-major) does not include or exclude
> a commitment to maintaining backwards compatibility. it consists of
> nothing more or less than deciding to adopt a new label. when someone
> wants to make a change that is not backwards compatible then this is
> when we should make a decision.
You "lead" this effort now, so let's play your game :-)
> no plan is necessary at this time. planning in the abstract has a
> tendency to lead to unnecessary friction. when someone has a concrete
> proposal that really requires breaking storage/configuration
> compatibility then we can decide what to do at that time.
In past friction has been created by concrete plans and not by abstract
things (I can provide links to threads if you are interested in the
social analysis). While things remained abstract enough everyone was
happy to dream about his own idea of real "implementation".
Concreteness, here, led to friction. But this is past, and shit happens.
Stefano
PS: sorry for having hijacked the vote topic. I won't do this anymore..
or at least I'll try ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/31/07, Stefano Bagnara <ap...@bago.org> 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 cut.
>
> I read this as 3.0 *will* *be* backward compatible. If any backward
> incompatibility is introduced it must be introduced as experimental
> module: am I understanding your words right?
perhaps
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 storage/configuration compatibility. this may mean
forking some modules and decoupling more parts of the system.
3 i would prefer to see 3.0 storage/configuration compatible by
default but users able to choose new, incompatible solutions
4 i would prefer to see more development on trunk and less on branches
> 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 you mean by core. an example would be useful.
the next step in the modularisation needs to be factoring out features
from the core into API, library and functions. with a little bit of
luck and some refactoring, i hope that core module can be eliminated.
i do accept that some forking of some functional modules will be
necessary but IMO this is good since it allows new approaches to be
developed whilst retaining the more mature code
> That said I'm fine with this (I'm fine with almost anything that will
> give JAMES Server an early release): I just would like to know if OTHERS
> are also fine with this. I hope they will explain this while voting the
> 3.0, or otherwise I hope someone will take care of understanding this in
> the near future.
IMHO this is a bridge that should be crossed we come to it
dubbing trunk 3.0 (rather than next-major) does not include or exclude
a commitment to maintaining backwards compatibility. it consists of
nothing more or less than deciding to adopt a new label. when someone
wants to make a change that is not backwards compatible then this is
when we should make a decision.
> >> In fact I think it should be better to define what to release and then
> >> define the number to use, but I'm fine with *any* number as long as it
> >> doesn't affect releasing asap (trivia: the trunk in 2004 was named 3.0).
> >> I would like to know if the goal to keep storage/config.xml
> >> compatibility is a priority in the 3.0 or not: IMHO this is the only
> >> important thing to be able to dedice what can be included in trunk and
> >> what will have to wait for trunk to become a branch.
> >
> > i think that it helps to have a good name for a distant collective goal
> >
> > - robert
>
> I completely agree. next-* labels were simple temporary workarounds,
> waiting for this vote (in fact they was supposed to disappear on
> dec2006/jan2007 but things screwed up).
>
> What I don't like is that we vote on 3.0 without having some sort of
> agreement/understanding on what kind of changes we expect to accept in
> trunk and what instead we expect to not accept in trunk so this kind of
> vote would scary me as hell if I was still active and working on
> message/envelope refactoring and repositories refactoring ;-)
hopefully we might be able to tempt you back into active development
one day soon ;-)
this is just a label change
no plan is necessary at this time. planning in the abstract has a
tendency to lead to unnecessary friction. when someone has a concrete
proposal that really requires breaking storage/configuration
compatibility then we can decide what to do at that time.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Stefano Bagnara <ap...@bago.org>.
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. If any backward
incompatibility is introduced it must be introduced as experimental
module: am I understanding your words right?
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 said I'm fine with this (I'm fine with almost anything that will
give JAMES Server an early release): I just would like to know if OTHERS
are also fine with this. I hope they will explain this while voting the
3.0, or otherwise I hope someone will take care of understanding this in
the near future.
>> In fact I think it should be better to define what to release and then
>> define the number to use, but I'm fine with *any* number as long as it
>> doesn't affect releasing asap (trivia: the trunk in 2004 was named 3.0).
>> I would like to know if the goal to keep storage/config.xml
>> compatibility is a priority in the 3.0 or not: IMHO this is the only
>> important thing to be able to dedice what can be included in trunk and
>> what will have to wait for trunk to become a branch.
>
> i think that it helps to have a good name for a distant collective goal
>
> - robert
I completely agree. next-* labels were simple temporary workarounds,
waiting for this vote (in fact they was supposed to disappear on
dec2006/jan2007 but things screwed up).
What I don't like is that we vote on 3.0 without having some sort of
agreement/understanding on what kind of changes we expect to accept in
trunk and what instead we expect to not accept in trunk so this kind of
vote would scary me as hell if I was still active and working on
message/envelope refactoring and repositories refactoring ;-)
This is not the case, so I'm relaxed and excited that something is
moving toward a release!!
Thank you for taking care of this!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/31/07, Stefano Bagnara <ap...@bago.org> 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
> > decide that a future release from this code stream will be designated
> > 3.0.
>
> This is not correct,
(IMHO correct but incomplete: the artifacts created by the trunk build
are named next-major)
> let me explain:
> next-major was the name assigned to a tentative release and branching
> trunk was in the plan for next-major. The difference between trunk and
> next-major was in the planning/scheduling and was present in JIRA when
> we used this labels to discuss what was going to land next-major
> (storage/config compatible) and what would have had to wait the
> following (storage/config incompatible).
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.
> > dubbing trunk 3.0 does imply that if the 2.x code base requires a new
> > major release then this will take the 4.0 designation. i have no
> > problem with that contingency.
>
> I don't understand this sentence. Can you explain?
> AFAIK no one ever though to create major releases starting from the 2.x
> branches. The only proposal we had was for a minor release based on 2.x
> (and if Noel will come back sooner or later with this goal I think we
> all already agreed on the 2.4 number)
just thinking about contingencies: would probably have been cleaner
and clearer to avoid speculating about the future right now.
<snip>
> In fact I think it should be better to define what to release and then
> define the number to use, but I'm fine with *any* number as long as it
> doesn't affect releasing asap (trivia: the trunk in 2004 was named 3.0).
> I would like to know if the goal to keep storage/config.xml
> compatibility is a priority in the 3.0 or not: IMHO this is the only
> important thing to be able to dedice what can be included in trunk and
> what will have to wait for trunk to become a branch.
i think that it helps to have a good name for a distant collective goal
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Stefano Bagnara <ap...@bago.org>.
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 designated
> 3.0.
This is not correct, let me explain:
next-major was the name assigned to a tentative release and branching
trunk was in the plan for next-major. The difference between trunk and
next-major was in the planning/scheduling and was present in JIRA when
we used this labels to discuss what was going to land next-major
(storage/config compatible) and what would have had to wait the
following (storage/config incompatible).
> dubbing trunk 3.0 does imply that if the 2.x code base requires a new
> major release then this will take the 4.0 designation. i have no
> problem with that contingency.
I don't understand this sentence. Can you explain?
AFAIK no one ever though to create major releases starting from the 2.x
branches. The only proposal we had was for a minor release based on 2.x
(and if Noel will come back sooner or later with this goal I think we
all already agreed on the 2.4 number)
> here's my +1
>
> i'll tally this vote no earlier than friday the 3rd of August 1200GMT
>
> - robert
>
> -- 8< ----------------------------------------------------
> [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 or A1
(in 2.x we used the A1, A2, B1, B2, RC1... as suffixes) could be the
suffix of the first public milestone/alpha release.
In fact I think it should be better to define what to release and then
define the number to use, but I'm fine with *any* number as long as it
doesn't affect releasing asap (trivia: the trunk in 2004 was named 3.0).
I would like to know if the goal to keep storage/config.xml
compatibility is a priority in the 3.0 or not: IMHO this is the only
important thing to be able to dedice what can be included in trunk and
what will have to wait for trunk to become a branch.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Serge Knystautas <sk...@gmail.com>.
On 7/31/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> -- 8< ----------------------------------------------------
> [x] +1 Dub trunk 'JAMES 3.0'
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Bernd Fondermann <be...@googlemail.com>.
[ X] +1 Dub trunk 'JAMES 3.0'
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by norman <no...@apache.org>.
> -- 8< ----------------------------------------------------
> [x] +1 Dub trunk 'JAMES 3.0'
> [ ] +0 Sounds reasonable
> [ ] -0 Sounds unreasonable
> [ ] -1 Find another name
> ----------------------------------------------------------
>
Thx for all your efforts.
Bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/31/07, Stefano Bagnara <ap...@bago.org> 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
> > -SNAPSHOT) is more appropriate for nightly builds/snapshots. M1 or A1
> > (in 2.x we used the A1, A2, B1, B2, RC1... as suffixes) could be the
> > suffix of the first public milestone/alpha release.
>
> To be more clear my +1 is to have the first 3.0 milestones/alphas cut
> from trunk. I'm not, currently, agreeing on releasing 3.0 RCs and final
> from trunk (unless there is clear proof this won't slow down any other
> non 3.0 related activity).
no vote at apache really commits anyone to anything other than the
immediate action. the future will look after itself in due course.
so, there's no need to commit to anything other than agreeing that 3.0
is a better label for trunk than next-major
> My opinion is that sooner or later the 3.0 release process will require
> stabilization/consolidation and a branch will better fit the goal so to
> leave trunk open to innovation and new features.
probably but there's no need to take that decision now
> It is really difficult to tell now when a branch will be needed as "3.0"
> is only a label (as "next-major" was), but, if I don't miss anything, it
> does not have a specification yet (backward compatibility level
> required, JVM dependency...)
yes - my proposal is simply to change the label for trunk from next-major to 3.0
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] next-major from trunk will be 3.0
Posted by Stefano Bagnara <ap...@bago.org>.
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 or A1
> (in 2.x we used the A1, A2, B1, B2, RC1... as suffixes) could be the
> suffix of the first public milestone/alpha release.
To be more clear my +1 is to have the first 3.0 milestones/alphas cut
from trunk. I'm not, currently, agreeing on releasing 3.0 RCs and final
from trunk (unless there is clear proof this won't slow down any other
non 3.0 related activity).
My opinion is that sooner or later the 3.0 release process will require
stabilization/consolidation and a branch will better fit the goal so to
leave trunk open to innovation and new features.
It is really difficult to tell now when a branch will be needed as "3.0"
is only a label (as "next-major" was), but, if I don't miss anything, it
does not have a specification yet (backward compatibility level
required, JVM dependency...)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org