Maybe we should consider switching to semantic versioning. Particularly since we are starting to use Maven more, It might help those who use Maven to manage their dependencies. http://semver.org/
-----Original Message----- From: Javen O'Neal [mailto:javenon...@gmail.com] Sent: Monday, August 22, 2016 12:36 PM To: POI Developers List <dev@poi.apache.org> Subject: Re: [VOTE] Apache POI 3.15 (RC1) Cell.CELL_TYPE_NUMERIC -> CellType.NUMERIC Agreed. Communication of backwards-breaking changing is crucial. I also failed to update https://poi.apache.org/spreadsheet/quick-guide.html#CellContents and probably poi-examples. Aside from including this in the release notes, can we add some kind of indicator on https://poi.apache.org/changes.html indicating that a bug add/fix is a breaking change? This would save time for developers reviewing the changelog and updating their code without needing to read through every bug. I started adding the affected POI module to my bugs to make the changelog more useful. Perhaps a table format would be better. Bonus points if we can build this table from bugzilla: module, title, and Enhancement/Fix is already in bugzilla. Add or Fix? | Breaks Compatibility? | Affected Modules | Bug number | Description/Title <Add Icon> | Yes | SS Common | <bzlink>59791</bzlink> | migrate cell type constants from Cell to CellType enum <Fix Icon> | <blank> | XSSF | <bzlink>59775</bzlink> | correctly recognized URL hyperlinks containing a hash mark Alternatively, break the changelog for each release into two sections: backwards-breaking and non-backwards breaking. How would we categorize binary-only backwards compatibility breakage? Recompiling a project is pretty low effort for projects with a build automation tool, so I'd be inclined to exclude binary-only breakages. On Mon, Aug 22, 2016 at 8:30 AM, Dominik Stadler <dominik.stad...@gmx.at> wrote: > Hi, > > Oh, sorry for the false alarm, this seems to be a problem with my > compare-tool (Beyond Compare), it displays two test-documents as being > contained on top-level of the src-tar.gz. When extracting via other > tools I don't see those. > > So I am +1 here! > > However I saw that we do actually break some stuff with all the > Enum-rework, e.g. the following will not work any more out of the box: > > switch (cell.getCellType()) { > case Cell.CELL_TYPE_NUMERIC: > > Unfortunately a switch on teh CellType is quite common, so we need to > explain this in the release notes and I think we should be a bit more > conservative with all those refactorings/deprecations in the future to > not cause too much change in those places! > > Dominik. > > > On Mon, Aug 22, 2016 at 11:10 AM, David North <dno...@apache.org> wrote: > >> Your image didn't come through. I see the following inside the >> poi-3.15 directory of poi-src-3.15-20160828.zip: >> >> legal >> osgi >> sonar >> src >> test-data >> build.xml >> forrest.properties >> KEYS >> LICENSE >> NOTICE >> patch.xml >> >> Which are unwanted? This seems to match the src packages in the last beta. >> >> Thanks, >> David >> >> On 22/08/16 07:47, Dominik Stadler wrote: >> > Sorry, me again, >> > >> > Unfortunately there are still some unwanted artifacts in the >> > src-package, can you remove those as well? >> > >> > >> > Inline image 1 >> > >> > While not blocking the release, but the Java version used for the >> > build seems to be "1.6.0_34", which is a bit outdated, latest (and >> > last) version of Java 6 is patchlevel 45, would look better to use >> > this one to build releases. >> > >> > Dominik. >> > >> > >> > On Mon, Aug 22, 2016 at 12:49 AM, David North <dno...@apache.org >> > <mailto:dno...@apache.org>> wrote: >> > >> > Vote begins now and ends at 11:55 BST 2016-08-23 >> > >> > Artifacts are here: >> > >> > https://dist.apache.org/repos/dist/dev/poi/3.15-RC1/ >> > <https://dist.apache.org/repos/dist/dev/poi/3.15-RC1/> >> > >> > Usual checks required (does it work? does the distribution look >> right?), >> > only more so as this is an RC for a non-beta release. >> > >> > +1 from me. >> > >> > As those of you watching the commits may have seen, I can't get >> > the >> svn >> > commits from ant to work on either of my machines (Debian stable or >> > Fedora 22) - I thought I'd fixed it by upgrading to svn 1.9, but >> > seemingly not. I've therefore replaced them with "exec" tasks calling >> > the SVN command line client. This needs further investigation. >> > >> > I also had to manually strip out the spurious "trunk" directory >> > from >> the >> > src zip/tar, so that's another fix needed somewhere in the build >> > scripts. >> > >> > Thanks, >> > >> > -- >> > David North | www.dnorth.net <http://www.dnorth.net> >> > >> > >> >> -- >> David North - Committer and PMC Member, Apache POI >> https://home.apache.org/~dnorth/ >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
