Hi!
+1 for M4 soon and before merging back
Big changes tend to have big bugs, so these changes have to be well tested.
Steve
> Emmanuel Lecharny [mailto:[EMAIL PROTECTED] wrote
>
> Hi guys,
>
> what about releasing a 2.0.0-M4 soon ? As I've worked those last few
> weeks on MINA in order to get i
Steve Ulrich wrote:
Hi!
+1 for M4 soon and before merging back
Big changes tend to have big bugs, so these changes have to be well tested.
I think that we have room for many milestones before a 2.0. Moving from
milestone to milestone while adding new features is easier than doing a
big bang
On Tue, Nov 18, 2008 at 10:17 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> I think that we have room for many milestones before a 2.0.
I still think we should aim to get 2.0 out, without any major changes.
After that, we can start thinking of 2.1 or 3.0. So, I would not like
to do many more
[
https://issues.apache.org/jira/browse/FTPSERVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648561#action_12648561
]
Gary Bell commented on FTPSERVER-205:
-
Ok, FTPSERVER-218 added a refresh() method to
Hi guys,
I think it's time to stop discussing for ever and to start a vote.
MINA 2.0.0-Mx is around for months now, and we have more and more users
developing applications around it. We have tons of proposal to improve
MINA, but many of them are pretty drastic, and may jeopardize our users'
i
[X] Freeze the code, move to MINA 2.0-RC1
On Tue, Nov 18, 2008 at 6:04 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> I think it's time to stop discussing for ever and to start a vote.
>
> MINA 2.0.0-Mx is around for months now, and we have more and more users
> developing applica
Emmanuel Lecharny wrote:
[] Continue to add new features to MINA 2.0 milestones until we reach a
stable point
[] Freeze the code, move to MINA 2.0-RC1
[] I abstain
Non-binding
[x] Freeze the code, move to MINA 2.0-RC1
Get 2.0 out, let users migrate, drop 1.0 and 1.1.
--
Eero Nevalainen
On Tue, Nov 18, 2008 at 12:04 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> [X] Freeze the code, move to MINA 2.0-RC1
Let's go!
/niklas
[X] Freeze the code, move to MINA 2.0-RC1
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
[X] Freeze the code, move to MINA 2.0-RC1
On Nov 18, 2008, at 4:04 AM, wrote:
Hi guys,
I think it's time to stop discussing for ever and to start a vote.
MINA 2.0.0-Mx is around for months now, and we have more and more
users developing applications around it. We have tons of proposal to
> Emmanuel Lecharny [mailto:[EMAIL PROTECTED] wrote:
>
> [] Continue to add new features to MINA 2.0 milestones until we reach a
> stable point
> [X] Freeze the code, move to MINA 2.0-RC1
> [] I abstain
>
> If we select (1), we will have to determinate the clear roadmap,
> otherwise we won't be abl
[x] Freeze the code, move to MINA 2.0-RC1
> Get 2.0 out, let users migrate, drop 1.0 and 1.1.
+1 1.0 and 1.1 have been supported some significant time moreover generally
speaking 1.0 to 2.0 is a breeze
and imporves perfs so we can consider that our users can migrate fast and at a
low cost.
This
This will allow on focusing a big road map for 3.0 maybe hitting some 2.1,2.2 on the road to progressively
introduce some changes and see how community reacts to them.
May I suggest that we use a clear notation for 'unstable' versions? With
the current one (ie, 2.0.0-Mx), people tend to thin
I've a couple of classes to handle the ASCII transfer mode. Since
these classes are inherited from InputStream and OutputStream, you
should be able to plug these in very easily by just wrapping the
original stream into the new stream. I used these classes in my FTP
Client implementation. We should
You're right using a N.5 notation for instable work in progress is ok to me
2.0.0-Mx should indeed be used for an almost frozen API (sometimes minor
changes that can't be postponed are needed)
N.0.x are and should be bug fixes
By drawing aside N.1 and N.2 do you mean we will only do bug fixes on
Edouard De Oliveira wrote:
By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the 2.0 branch and new features will only
go to 2.5 branch ? I'm not saying i disagree i just want to make your statement more clear.
This is exactly what I have in mind. However, it's just a conve
[
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reassigned DIRMINA-638:
-
Assignee: Emmanuel Lecharny
> DefaultSocketSessionConfig creates some connection
[
https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reassigned DIRMINA-628:
-
Assignee: Emmanuel Lecharny
> Windows Firewall security issue when configuring s
[
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648623#action_12648623
]
Emmanuel Lecharny commented on DIRMINA-638:
---
It should be fixed in 2.0.0-M3-SNAP
[
https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648624#action_12648624
]
Emmanuel Lecharny commented on DIRMINA-628:
---
It should be fixed in 2.0 trunk :
h
[
https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-628:
--
Affects Version/s: (was: 2.0.0-M3)
Fix Version/s: (was: 2.0.0-M4)
Fixe
[
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-638:
--
Affects Version/s: (was: 2.0.0-M3)
Fix Version/s: (was: 2.0.0-M4)
Just
On Tue, 18 Nov 2008 12:04:14 +0100
Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> I think it's time to stop discussing for ever and to start a vote.
>
> MINA 2.0.0-Mx is around for months now, and we have more and more
> users developing applications around it. We have tons of propo
[x] Freeze the code, move to MINA 2.0-RC1
But I agree with Julien, that the docs should improve before going to RC
-1 for "using a N.5 for unstable versions, and N.0 for stable versions."
I really dislike conventions based on numbers. We already discussed this in
the past : http://mina.markmail.
[
https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648680#action_12648680
]
David Latorre commented on FTPSERVER-136:
-
Patch applied in 718667.
The soluti
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reassigned DIRMINA-539:
-
Assignee: Emmanuel Lecharny (was: Julien Vermillard)
> NioDatagramConnector doe
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648684#action_12648684
]
Emmanuel Lecharny commented on DIRMINA-539:
---
I think that all those checks (can
Maarten Bosteels wrote:
[x] Freeze the code, move to MINA 2.0-RC1
But I agree with Julien, that the docs should improve before going to RC
We just have to define a clear roadmap for doco. What about releasing
2.0.0-M4, and fix the doco for 2.0.0-RC1 ?
-1 for "using a N.5 for unstable versio
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648692#action_12648692
]
Emmanuel Lecharny commented on DIRMINA-539:
---
What we can do is something like :
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648705#action_12648705
]
Edouard De Oliveira commented on DIRMINA-539:
-
what about this one ?
boolean
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648780#action_12648780
]
Emmanuel Lecharny commented on DIRMINA-539:
---
Well, itwon't work :
- first, you d
[
https://issues.apache.org/jira/browse/DIRMINA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edouard De Oliveira closed DIRMINA-576.
---
Resolution: Invalid
As you state, this is a jdk bug we cannot circumvent as long as
[
https://issues.apache.org/jira/browse/DIRMINA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edouard De Oliveira closed DIRMINA-388.
---
Resolution: Incomplete
It is lacking javadoc and as there is pretty enough examples
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648825#action_12648825
]
Edouard De Oliveira commented on DIRMINA-539:
-
indeed, the example was just in
[
https://issues.apache.org/jira/browse/DIRMINA-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edouard De Oliveira closed DIRMINA-234.
---
Resolution: Won't Fix
No recent work on this one and we now have asyncweb project
so
[
https://issues.apache.org/jira/browse/DIRMINA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edouard De Oliveira closed DIRMINA-555.
---
Resolution: Invalid
this sqhould be an asyncweb feature request
link does not work
[
https://issues.apache.org/jira/browse/DIRMINA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648848#action_12648848
]
Edouard De Oliveira commented on DIRMINA-23:
very old issue
is there any sense
[
https://issues.apache.org/jira/browse/DIRMINA-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edouard De Oliveira resolved DIRMINA-623.
-
Resolution: Fixed
Fix Version/s: 2.0.0-M4
Assignee: Edouard De Ol
[
https://issues.apache.org/jira/browse/DIRMINA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591162#action_12591162
]
vcdaniel edited comment on DIRMINA-555 at 11/18/08 10:48 PM:
---
39 matches
Mail list logo
