Hi Rory,

Thanks for your opinion -- but may I note that even if
It's a major releases, there may be (some|many) existing
Clients which are not broken even if they upgrade,
Depending on what APIs their client code currently uses.

Breaking clients for no good reason just isn't playing
Nice with the clients IMHO, although you are right that
You do have the chance doing so in a major release.

At any rate, I wouldn't call the discussion irrelevant.
It is relevant for clients picking up commons net when
They migrate from 1.x to 2.x, and depending on what
The clients do and how many different ones there are,
Even Eclipse Ctrl+Shift+O can sum up to a non-trivial
Amount of total work on behalf of the clients.

I'm all in favor of code cleanup and refactoring when 
I see clear advantages, but not at any price.

For our FTP clients, I'd love to see customers being
Able to exchange net 1.5 against net 2.0 pre-compiled
Binaries in the final product if possible.

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 

> -----Original Message-----
> From: Rory Winston [mailto:[EMAIL PROTECTED] 
> Sent: Mittwoch, 21. Mai 2008 00:57
> To: Commons Developers List
> Subject: Re: Commons Net 1.5 / 2.0 Releases
> 
> Can I just add, it's a major release (1.5 -> 2.0).
> 
> 
> Rory Winston wrote:
> > This is totally irrelevant. It's called refactoring.
> >
> >
> > Oberhuber, Martin wrote:
> >> I agree that I cannot see a strong argument for such a
> >> Breaking change. In general, binary backward compatibility
> >> For a lib with such a wide distribution should be maintained
> >> If there are no strong arguments against maintaining it.
> >>
> >> In this case, it looks like the various clients are small
> >> Enough to live in a single package.
> >>
> >> Cheers,
> >> -- 
> >> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> >> Target Management Project Lead, DSDP PMC Member
> >> http://www.eclipse.org/dsdp/tm
> >>  
> >>  
> >>
> >>  
> >>> -----Original Message-----
> >>> From: Rory Winston [mailto:[EMAIL PROTECTED] Sent: 
> Montag, 19. 
> >>> Mai 2008 23:19
> >>> To: Commons Developers List
> >>> Subject: Re: Commons Net 1.5 / 2.0 Releases
> >>>
> >>> I think this was just a logical reorganization of the 
> source code. A 
> >>> lot of stuff was bundled in together that probably should 
> have been 
> >>> in separate packages for clarity in the first place. I dont think 
> >>> these classes are widely used at all. If they are, its a pretty 
> >>> simple matter to fix (CTRL+SHIFT+O in Eclipse will fix it 
> instantly, 
> >>> for instance).
> >>>
> >>> Rory
> >>>
> >>> Niall Pemberton wrote:
> >>>    
> >>>> >From a quick scan of Net 2.0 the there has been the following
> >>>> re-organization in Net 2.0:
> >>>>
> >>>> o.a.c.n.CharGenTCPClient moved to o.a.c.n.chargen package
> >>>> o.a.c.n.CharGenUDPClient moved to o.a.c.n.chargen package
> >>>> o.a.c.n.DaytimeTCPClient moved to o.a.c.n.daytime package
> >>>> o.a.c.n.DaytimeUDPClient moved to o.a.c.n.daytime package
> >>>> o.a.c.n.DiscardTCPClient moved to o.a.c.n.discard package
> >>>> o.a.c.n.DiscardUDPClient moved to o.a.c.n.discard package
> >>>> o.a.c.n.EchoTCPClient moved to o.a.c.n.echo package
> >>>> o.a.c.n.EchoUDPClient moved to o.a.c.n.echo package
> >>>> o.a.c.n.FingerClient moved to o.a.c.n.finger package
> >>>> o.a.c.n.TimeTCPClient moved to o.a.c.n.time package
> >>>> o.a.c.n.TimeUDPClient moved to o.a.c.n.time package
> >>>> o.a.c.n.WhoisClient moved to o.a.c.n.whois package
> >>>>
> >>>> Are these package moves necessary - looks like were just going to
> >>>> inflict unecessary pain on the users? If the Net devs 
> still       
> >>> think its
> >>>    
> >>>> a good idea, then it would provide users with an upgrade 
> path if the
> >>>> the new packages are added in Net 1.5 and the old classes       
> >>> with the old
> >>>    
> >>>> package names deprecated.
> >>>>
> >>>> Niall
> >>>>
> >>>> On Mon, May 19, 2008 at 6:29 PM, Niklas Gustavsson       
> >>> <[EMAIL PROTECTED]> wrote:
> >>>    
> >>>>        
> >>>>> I would prefer to get 2.0 out there as well. I would         
> >>> rather see us be
> >>>    
> >>>>> fixing bugs as found by users than keeping it around 
> for         
> >>> even longer
> >>>    
> >>>>> in the current state. It's time to get it out there.
> >>>>>
> >>>>> /niklas
> >>>>>
> >>>>> On Mon, May 19, 2008 at 6:35 PM, sebb <[EMAIL PROTECTED]> wrote:
> >>>>>            
> >>>>>> I think 1.5 is closer to being ready for a release than 2.0.
> >>>>>>
> >>>>>> Given that any bugs that are found in 1.5 are probably 
> going to be
> >>>>>> present in 2.0 as well, I would like to suggest that 
> 1.5           
> >>> is released
> >>>    
> >>>>>> first, and 2.0 after there has been some time for 
> people           
> >>> to use 1.5 in
> >>>    
> >>>>>> earnest.
> >>>>>>
> >>>>>> Are there any JIRA issues which still need to be fixed for 1.5?
> >>>>>>
> >>>>>>
> >>>>>> On 17/05/2008, Rory Winston <[EMAIL PROTECTED]> wrote:
> >>>>>>                
> >>>>>>> Martin/Sebb
> >>>>>>>
> >>>>>>>  Are we ready to cut another RC? I can do so if you guys 
> >>>>>>>             
> >>> are happy with
> >>>    
> >>>>>>> where we're at.
> >>>>>>>
> >>>>>>>  Rory
> >>>>>>>
> >>>>>>>
> >>>>>>>  Oberhuber, Martin wrote:
> >>>>>>>
> >>>>>>>                    
> >>>>>>>> Hi all,
> >>>>>>>>  just wondering, what's currently holding off a release 
> >>>>>>>>               
> >>> of Commons Net
> >>>    
> >>>>>>>> 1.5 / 2.0?
> >>>>>>>>  Many issues have been sorted out after the last     
>           
> >>> release candidates, when
> >>>    
> >>>>>>>> can
> >>>>>>>> we expect a new RC to review? Is there anything      
>          
> >>> particular that I could
> >>>    
> >>>>>>>> help
> >>>>>>>> with?
> >>>>>>>>  Cheers,
> >>>>>>>> -- 
> >>>>>>>> Martin Oberhuber, Senior Member of Technical Staff, 
> Wind River
> >>>>>>>> Target Management Project Lead, DSDP PMC Member
> >>>>>>>> http://www.eclipse.org/dsdp/tm
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>                         
> >>> 
> ---------------------------------------------------------------------
> >>>    
> >>>>>>>  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>>>  For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>>>
> >>>>>>>
> >>>>>>>                     
> >>> 
> ---------------------------------------------------------------------
> >>>    
> >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>>
> >>>>>>
> >>>>>>                 
> >>> 
> ---------------------------------------------------------------------
> >>>    
> >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>>
> >>>>>
> >>>>>             
> >>>>       
> >>> 
> ---------------------------------------------------------------------
> >>>    
> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>         
> >>> 
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>     
> >>
> >> 
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >>   
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to