> -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Thursday, July 08, 2010 08:19 > To: Commons Developers List > Subject: Re: [NET] 2.0 Change to nntp classes - using int instead of long for > article ids > > On 8 April 2010 03:10, sebb <seb...@gmail.com> wrote: > > On 31/03/2010, sebb <seb...@gmail.com> wrote: > >> The fix for NET-276 involved public API changes so is not appropriate > >> for a minor release. > >> > >> NNTPClient#retrieveArticleInfo(int,int) > >> was changed to > >> NNTPClient#retrieveArticleInfo(long, long) > >> > >> That can easily be fixed by adding the old method and deprecating it. > >> > >> There are also some changes to NewsgroupInfo: > >> > >> Return type of method 'public int getArticleCount()' has been changed to > long > >> Return type of method 'public int getFirstArticle()' has been changed to > long > >> Return type of method 'public int getLastArticle()' has been changed to > long > >> > >> and ArticlePointer: > >> > >> Changed type of field articleNumber from int to long > >> > >> It's not so obvious how to fix the API change here. > >> > >> It also looks to me like the change is incomplete - there are still > >> quite a few API methods in NNTPClient which still use an int rather > >> than a long, and Article.articleNumber is an int. > >> > >> Seems to me that articleNumber should be long throughout; also ideally > >> more use should be made of ArticlePointer (e.g. Article should use > >> it). > >> > >> I think the int/long change needs to be resolved before any release is > made. > >> > > > > Ping? Any views on this? > > > > Regardless of the API change, the nntp code is not consistent at present. > > > > I propose: > > * the incompatible NNTP changes are reverted. > * we release NET 2.1 without the NNTP fixes, and hope to resolve them later
I would table all int vs. long changes and start a 3.0 release train with those changes. > > Any other views? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org