You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
(11) |
Mar
(17) |
Apr
(12) |
May
(2) |
Jun
(20) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(5) |
2011 |
Jan
(4) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(5) |
Jun
|
Jul
(12) |
Aug
(4) |
Sep
(5) |
Oct
(1) |
Nov
(38) |
Dec
(27) |
2012 |
Jan
(46) |
Feb
(182) |
Mar
(83) |
Apr
(22) |
May
(68) |
Jun
(47) |
Jul
(135) |
Aug
(84) |
Sep
(57) |
Oct
(45) |
Nov
(27) |
Dec
(61) |
2013 |
Jan
(59) |
Feb
(78) |
Mar
(66) |
Apr
(107) |
May
(27) |
Jun
(56) |
Jul
(53) |
Aug
(3) |
Sep
(19) |
Oct
(41) |
Nov
(44) |
Dec
(54) |
2014 |
Jan
(49) |
Feb
(72) |
Mar
(22) |
Apr
(41) |
May
(63) |
Jun
(27) |
Jul
(45) |
Aug
(12) |
Sep
(3) |
Oct
(8) |
Nov
(27) |
Dec
(16) |
2015 |
Jan
(3) |
Feb
(20) |
Mar
(6) |
Apr
(4) |
May
(15) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(16) |
May
(9) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <tr...@do...> - 2013-04-22 17:34:35
|
<p>A new comment has been added to the following issue.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Subsequent sorts clauses in descending order</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Max</td> </tr> <tr> <td><b>Date:</b></td> <td>2013-04-22 06:33 PM</td> </tr> <tr> <td><b>Comment:</b></td> </tr> <tr> <td colspan="2"><p> Second issue found on the sort :</p> <p> second ORDER clause is not processed if the first clause is unbound</p></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=350" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=350</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-22 17:11:42
|
<p>The following issue has been added to a project that you are monitoring.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Subsequent sorts clauses in descending order</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Max</td> </tr> <tr> <td><b>Milestone:</b></td> <td>Unassigned</td> </tr> <tr> <td><b>Category:</b></td> <td>Query</td> </tr> <tr> <td><b>Priority:</b></td> <td>Unassigned</td> </tr> <tr> <td><b>Type:</b></td> <td>Bug</td> </tr> <tr> <td><b>Description:</b></td> </tr> <tr> <td colspan="2"><p> Observed on release 0.9.0 rc4</p> <p> In a query with multiple ORDER BY clauses like</p> <p> SELECT ?sort1 ?sort2 ?sort3 {...} ORDER BY ?sort1 desc(?sort2) ?sort3</p> <p> The Sparql result are ordered with sort2 and sort3 values both in descending order</p> <p> Generally whenever a sort is set to descending direction, subsequent sort clauses are also returned in descending order event is asc(?sortN) is specified.</p></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=350" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=350</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: Tomasz P. <tom...@gm...> - 2013-04-21 15:54:23
|
Hi guys Here's an update on my work setting up TeamCity. I've got all the changes done do that the project builds and tests are run [1], and I'm creating NuGet packages as discussed earlier [2, 3]. Mercurial automatically triggers builds. When a build is successful and all tests pass, NuGet packages are created. The packages are named as discussed earlier and. What remains is to add automatic publishing for prerelease builds and manual for stable builds. I also think that the tags should be created in the repository only when a package is released publicly on NuGet. Otherwise I don't think it should be done. Rob, please tell me what important steps I might have missed in TeamCity that you would have done with the dotnetrdf.build script. Also there is a number of further issues: 1. MSBuild can't build vdproj setup packages. I may have to install Visual Studio after all. 2. None of the tests, which require the UnitTestConfig.propertie file are currently run. 3. I have noticed that some tests aren't independent from outside world, like the recently failed SparqlDatasetDefaultGraphManagementWithUpdate tests, which failed because dotnetrdf.org returned HTTP code 503. I think we should work on making these tests as self-sustaining as possible 4. Other thatn that some tests still fail, and these should be corrected before TeamCity will produce any NuGet package at all 5. I would like to merge my changes to default branch. Please review the changes in my fork [4]. Thanks, Tom [1]: http://ci.t-code.pl/viewType.html?buildTypeId=bt2 [2]: http://ci.t-code.pl/viewType.html?buildTypeId=bt4 [3]: http://ci.t-code.pl/viewType.html?buildTypeId=bt5 [4]: https://bitbucket.org/tpluscode/dotnetrdf-teamcity On Thu, Apr 18, 2013 at 10:45 PM, Tomasz Pluskiewicz <tom...@gm...> wrote: > Hi again > > I have been struggling to put those file somewhere on the system and > fool msbuild to use them but it didn't seem to work. > > I settled for a compromise, which is keeping the files in a separate > repo [1], which is fetched on top of the main files and the Phone > csproj is patched as needed. Now all builds fine and we won't need to > pollute the solution. > > Tom > > [1]: https://bitbucket.org/dotnetrdf/wp7hack > > On Wed, Apr 17, 2013 at 10:36 AM, Khalil Ahmed <ka...@ne...> wrote: >> Its probably Hyper-V that is causing the failure. If you are installing on >> to a machine that doesn't meet the requirements for Hyper-V then the >> emulator won't install. I think you are probably stuck with having to put >> the files somewhere - either in the repo or in some location external to the >> repo that is then configured in the build process. >> >> K >> >> >> On Wed, Apr 17, 2013 at 7:27 AM, Tomasz Pluskiewicz >> <tom...@gm...> wrote: >>> >>> Rob >>> >>> I did try that. Still, it fails on installing Windows Phone Emulator >>> x64. The error is something with VMM service, which I don't have and >>> couldn't find a way to install. >>> >>> However on second thought if I was able to put the WP7 files in repo I >>> should be able to copy them where they belong without installing and I >>> hope it will work too. >>> >>> Tom >>> >>> On Wed, Apr 17, 2013 at 12:24 AM, Rob Vesse <rv...@do...> wrote: >>> > Tom >>> > >>> > You can install WP7 tools on Windows Server 2008 because I used to build >>> > releases on my Server 2008 machine when I was at the University of >>> > Southampton >>> > >>> > See http://blogs.msdn.com/b/astebner/archive/2010/05/02/10005980.aspx >>> > which details the steps necessary, basically you have to extract the >>> > installer and modify a config file >>> > >>> > Rob >>> > >>> > On 4/16/13 1:30 PM, "Tomasz Pluskiewicz" <tom...@gm...> >>> > wrote: >>> > >>> >>Hi Rob, Kal >>> >> >>> >>I have been able to force TeamCity to build dotNetRDF with relatively >>> >>minimal changes. Please refer to my fork [1]. I have switched from >>> >>MSTest to NUnit and done some minor changes to csproj files. There is >>> >>also a proposal to change the integration tests to come out >>> >>inconclusive instead of failed when test config is missing... >>> >> >>> >>Most noteworthy is the latest commit in the 'WP7 Hack' branch. >>> >>Unfortunately I found out the hard way that Windows Phone SDK 7.1 is >>> >>not only unsuppported on Windows Server 2008 R2, it is completely >>> >>uninstallable! The only working solution I found was to stuff 14 MB of >>> >>WP7 SDK files and build targets and have the WindowsPhone project use >>> >>them instead of the defaults. This way the whole solution builds fine >>> >>from sln file using msbuild. >>> >> >>> >>You can have a look at the project here: http://ci.t-code.pl (guest >>> >>login enabled) >>> >> >>> >>Regarding your eariler emails, I think that version numbering should >>> >>be moved from solution to TeamCity completely. This way we can >>> >>flexibly control that number and pass it between build >>> >>steps/configurations. >>> >> >>> >>Next step will be to build and publish nuget packages. Satisfying >>> >>dependencies between packages will have to be done in some kind of >>> >>nuspec patching step to modify the <dependency> tags. Hence why we >>> >>need to control the version withing the CI server. >>> >> >>> >>I will write more when the TC configuration is more complete >>> >> >>> >>Tom >>> >> >>> >>[1]: https://bitbucket.org/tpluscode/dotnetrdf-teamcity >>> >> >>> >>> >> >>-------------------------------------------------------------------------- >>> >>---- >>> >>Precog is a next-generation analytics platform capable of advanced >>> >>analytics on semi-structured data. The platform includes APIs for >>> >> building >>> >>apps and a phenomenal toolset for data science. Developers can use >>> >>our toolset for easy data analysis & visualization. Get a free account! >>> >>http://www2.precog.com/precogplatform/slashdotnewsletter >>> >>_______________________________________________ >>> >>dotNetRDF-develop mailing list >>> >>dot...@li... >>> >>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>> > >>> > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > Precog is a next-generation analytics platform capable of advanced >>> > analytics on semi-structured data. The platform includes APIs for >>> > building >>> > apps and a phenomenal toolset for data science. Developers can use >>> > our toolset for easy data analysis & visualization. Get a free account! >>> > http://www2.precog.com/precogplatform/slashdotnewsletter >>> > _______________________________________________ >>> > dotNetRDF-develop mailing list >>> > dot...@li... >>> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>> >>> >>> ------------------------------------------------------------------------------ >>> Precog is a next-generation analytics platform capable of advanced >>> analytics on semi-structured data. The platform includes APIs for building >>> apps and a phenomenal toolset for data science. Developers can use >>> our toolset for easy data analysis & visualization. Get a free account! >>> http://www2.precog.com/precogplatform/slashdotnewsletter >>> _______________________________________________ >>> dotNetRDF-develop mailing list >>> dot...@li... >>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> >> >> >> >> -- >> Kal Ahmed >> Director, Networked Planet Limited >> e: kal...@ne... >> w: www.networkedplanet.com >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> |
From: Tomasz P. <tom...@gm...> - 2013-04-21 06:48:55
|
I was thinking that maybe the fluent queries could be merged back to trunk. Even though incomplete, should be in a stable enought state and we could get some user feedback. Other than that I noticed that latest Turtle/Sparql changes caused Silverlight builds to fail. I was able to fix one of those issues in commit 085ea4cc65d7 (missing Char methods in SL), but I'm not sure how to approach the other (you used SparqlConnectorLoadMethod in StorageFactory). Looks like like I could comment it out but I'm not sure. Tom On Fri, Apr 19, 2013 at 11:17 PM, Rob Vesse <rv...@do...> wrote: > Hey All > > I was originally going to try and push out 1.0.0 but I have decided to delay > by another week or two to try and get some extra stuff done. > > In particular some of the stuff in the CORE-314 branch (latest Turtle spec > support) highlighted another error in GraphMatcher and some general bugs in > Turtle parsing beyond those related to meeting the latest spec. I have code > in that branch passing the bulk of the tests (259 passed, 14 failed, 15 > indeterminate) and nothing fails fatally (I.e. stack traces) right now so > it's already in fairly good shape. I will likely merge what I have so far > to default anyway since it improves Turtle support even if it isn't yet > perfect and fixes the aforementioned issues. > > There is also the CORE-346 branch which has a new ReadWriteSparqlConnector > which is the update capable version of SparqlConnector which is stable and > passing the new tests I wrote for it. > > I would also like to at least look at CORE-349 (a bug with * in property > paths) in case there is a trivial fix there. > > Anything else small and self contained that people would like to get into > 1.0.0 if they can? > > Rob > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > |
From: <dot...@li...> - 2013-04-19 22:54:14
|
Send dotNetRDF-commits mailing list submissions to dot...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits or, via email, send a message with subject or body 'help' to dot...@li... You can reach the person managing the list at dot...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of dotNetRDF-commits digest..." Today's Topics: 1. commit/dotnetrdf: 6 new changesets (Bitbucket) 2. commit/dotnetrdf: 3 new changesets (Bitbucket) 3. commit/dotnetrdf: rvesse: Fix to test harness so many Turtle 1.1 tests that were reported as failing are now accurrately reported as passing (CORE-314) (Bitbucket) 4. commit/dotnetrdf: 2 new changesets (Bitbucket) 5. commit/dotnetrdf: 4 new changesets (Bitbucket) 6. commit/dotnetrdf: 2 new changesets (Bitbucket) 7. commit/dotnetrdf: 4 new changesets (Bitbucket) 8. commit/dotnetrdf: 2 new changesets (Bitbucket) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Apr 2013 00:10:49 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 6 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 6 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/246fc1d5b681/ Changeset: 246fc1d5b681 Branch: CORE-314 User: rvesse Date: 2013-04-18 01:16:18 Summary: Some minor tweaks to code around complex local name escapes, fixes a bug with accepting | instead of ! (CORE-314) Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/0e6c32187f13/ Changeset: 0e6c32187f13 Branch: CORE-314 User: rvesse Date: 2013-04-18 01:23:56 Summary: Fix the bug of decoding percent encodings in QNames when we are not supposed to decode them, fix up affected unit tests (CORE-314) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/663e8c178056/ Changeset: 663e8c178056 User: rvesse Date: 2013-04-18 01:24:24 Summary: Merge bug fixes for complex local name escapes in SPARQL from CORE-314 branch Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/f34110511821/ Changeset: f34110511821 Branch: CORE-314 User: rvesse Date: 2013-04-18 01:35:12 Summary: Modify TurtleTokeniser to call HandleComplexLocalNameEscapes() when appropriate (CORE-314) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5a45868d1475/ Changeset: 5a45868d1475 Branch: CORE-314 User: rvesse Date: 2013-04-18 01:40:47 Summary: Test suite refactoring ready to drop in official Turtle 1.1 suite (CORE-314) Affected #: 204 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/92d6e46967bf/ Changeset: 92d6e46967bf Branch: CORE-314 User: rvesse Date: 2013-04-18 02:08:52 Summary: Initial import of Turtle official test suite, not got this running in a usable way yet Affected #: 389 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 2 Date: Thu, 18 Apr 2013 19:25:37 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 3 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 3 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/892c0857e000/ Changeset: 892c0857e000 Branch: CORE-314 User: rvesse Date: 2013-04-18 18:48:43 Summary: Fix a bug in GraphMatcher highlighted by Turtle 1.1 tests (CORE-314, CORE-345) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e500b9d53d3c/ Changeset: e500b9d53d3c Branch: CORE-314 User: rvesse Date: 2013-04-18 19:59:31 Summary: More work on Turtle 1.1 support, breaks some existing Turtle support for now - BRANCH UNSTABLE (CORE-314) Affected #: 6 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/bbe4a2e917d5/ Changeset: bbe4a2e917d5 Branch: CORE-314 User: rvesse Date: 2013-04-18 21:25:20 Summary: More progress on Turtle 1.1, existing Turtle support should now be working again - BRANCH STABLE (CORE-314) Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 3 Date: Thu, 18 Apr 2013 20:09:33 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Fix to test harness so many Turtle 1.1 tests that were reported as failing are now accurrately reported as passing (CORE-314) To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/46d2263a3741/ Changeset: 46d2263a3741 Branch: CORE-314 User: rvesse Date: 2013-04-18 22:08:52 Summary: Fix to test harness so many Turtle 1.1 tests that were reported as failing are now accurrately reported as passing (CORE-314) Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 4 Date: Thu, 18 Apr 2013 22:02:58 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d6a22df12b7f/ Changeset: d6a22df12b7f Branch: CORE-314 User: rvesse Date: 2013-04-18 23:42:41 Summary: Refactoring of how TurtleTokeniser tokenising plain literals to simplify the logic for QName tokenisation (CORE-314) Affected #: 5 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/cc3e419487e5/ Changeset: cc3e419487e5 Branch: CORE-314 User: rvesse Date: 2013-04-19 00:02:46 Summary: Various fixes to Turtle QName validation logic, reduces failing W3C Turtle tests to 33 (CORE-314) Affected #: 3 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 5 Date: Thu, 18 Apr 2013 22:40:53 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 4 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 4 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/8646bcb72270/ Changeset: 8646bcb72270 Branch: CORE-314 User: rvesse Date: 2013-04-19 00:40:39 Summary: Test reporting tweak (CORE-314) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/6311eccfb01a/ Changeset: 6311eccfb01a Branch: CORE-314 User: rvesse Date: 2013-04-19 00:37:18 Summary: Support empty predicate object lists in Turtle (CORE-314) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e8ea46ac09da/ Changeset: e8ea46ac09da Branch: CORE-314 User: rvesse Date: 2013-04-19 00:30:59 Summary: Support standalone predicate object lists for Turtle (CORE-314) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/80bfeffc2320/ Changeset: 80bfeffc2320 Branch: CORE-314 User: rvesse Date: 2013-04-19 00:18:02 Summary: Another logic fix to Turtle QName validation (CORE-314) Affected #: 2 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 6 Date: Thu, 18 Apr 2013 23:08:02 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/4c18dfe4c28d/ Changeset: 4c18dfe4c28d Branch: CORE-314 User: rvesse Date: 2013-04-19 01:07:50 Summary: All stack trace producing failures in Turtle tests now fixed, still 14 failing tests (results not as expected) and 15 indeterminate tests (expected results unloadable) (CORE-314) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/7576e29e8176/ Changeset: 7576e29e8176 Branch: CORE-314 User: rvesse Date: 2013-04-19 00:57:49 Summary: Fix an error in the validation of numeric literal doubles in Turtle (CORE-314) Affected #: 3 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 7 Date: Fri, 19 Apr 2013 21:57:45 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 4 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 4 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/6578fa660528/ Changeset: 6578fa660528 User: rvesse Date: 2013-04-19 23:57:24 Summary: Merge ReadWriteSparqlConnector into default (CORE-346) Affected #: 11 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/cfb7c6f2cfe2/ Changeset: cfb7c6f2cfe2 Branch: CORE-346 User: rvesse Date: 2013-04-19 23:56:57 Summary: Close the CORE-346 branch now ReadWriteSparqlConnector is working Affected #: 0 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/80f7b34c4924/ Changeset: 80f7b34c4924 Branch: CORE-346 User: rvesse Date: 2013-04-19 23:56:37 Summary: Note ReadWriteSparqlConnector and related changes in Change Log (CORE-346) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/636b7698fe07/ Changeset: 636b7698fe07 Branch: CORE-346 User: rvesse Date: 2013-04-19 23:53:36 Summary: Make ReadWriteSparqlConnector properly support IConfigurationSerializable and add unit test Affected #: 4 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 8 Date: Fri, 19 Apr 2013 22:54:06 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/6adb6ab58916/ Changeset: 6adb6ab58916 User: rvesse Date: 2013-04-20 00:53:37 Summary: Merging in improvements to Turtle support for the W3C Candidate Recommendation, not yet 100% compliant but passes the vast majority of tests. Includes some fixes to original Turtle support and a bug fix for GraphMatcher (CORE-314, CORE-345) Affected #: 600 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/d3f6f67c9492/ Changeset: d3f6f67c9492 Branch: CORE-314 User: rvesse Date: 2013-04-20 00:52:11 Summary: Fix some regressions in test suite caused by Turtle parser refactoring (CORE-314) Affected #: 4 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ------------------------------ _______________________________________________ dotNetRDF-commits mailing list dot...@li... https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits End of dotNetRDF-commits Digest, Vol 7, Issue 4 *********************************************** |
From: Tomasz P. <tom...@gm...> - 2013-04-19 21:38:25
|
Numeric revision numbers aren't available on TeamCity. There is no way to view which revision such local number actually represents. I'm not even sure how TeamCity organizes it's local repositories. And if you add multiple build agents to the mix it becomes even more tricky and misleading. Tom On Fri, Apr 19, 2013 at 11:10 PM, Rob Vesse <rv...@do...> wrote: > Why can't we use the local HG numeric revision? > > While this isn't unique across clones if we have a single build server > responsible for builds that should be irrelevant since it will always > increment on that server > > Rob > > On 4/19/13 3:50 AM, "Tomasz Pluskiewicz" <tom...@gm...> > wrote: > >>Kal, >> >>Oh I see. I think I slightly misunderstood the prerelease feature >> >>So maybe let's do it this way. The current stable release is >>0.9.0.2110 and the upcoming is 1.0.0. This means that the automatic >>builds would be named >> >>1.0.0-prerelase2111 >>1.0.0-prerelase2112 >>1.0.0-prerelase2113 >> >>and the stable would be just 1.0.0.2114 or simply 1.0.0 at which point >>it will be bumped to 1.0.1 for the next batch of prerelease. Would >>that be more like whet SemVer is about? >> >>Regarding tracing back a build to HG revisions. There are some ways. >>One would be to include the commit hash in version string (not good >>IMO). There's also the VCS labelling feature in TeamCity. I just got >>it create a tag in my test repo [1]. The downside is there will be a >>swathe of tags but it's super easy to remove tags from time to time as >>a cleanup task. >> >>Tom >> >>[1]: >>https://bitbucket.org/tpluscode/dotnetrdf-teamcity/commits/c1f1ac2c6ab242d >>3d104e920b33718a89b2280b5 >> >>On Fri, Apr 19, 2013 at 10:55 AM, Khalil Ahmed <ka...@ne...> >>wrote: >>> Hi Tom, >>> >>> All looks fine to me. Though just to be clear this approach is >>>basically not >>> making use of the prerelease versioning functionality of NuGet, because >>> prerelease versioning in nuget is based on the value after the dash. It >>>all >>> works nicely though as NuGet will treat a stable 0.9.0.2116 release as >>>later >>> than a pre-release 0.9.0.2116-nightly130420 release. >>> >>> Will there be some way to tie build number back to some state of the Hg >>> repository ? >>> >>> Cheers >>> >>> Kal >>> >>> >>> On Thu, Apr 18, 2013 at 10:11 PM, Tomasz Pluskiewicz >>> <tom...@gm...> wrote: >>>> >>>> Hi >>>> >>>> There is one other way to proceed with unstable NuGet packages. We can >>>> set up TeamCity as a package repository. The downside is that we would >>>> have to require users to modify their setup. Having said that I'm too >>>> in favour of using the prerelease feature and having only one package >>>> stream. In fact I'd forgotten that feature exists. >>>> >>>> Unfortunately Rob's right and we will need to ensure correct >>>> dependencies but it should be fairly easy to achieve using the <style> >>>> target of NAnt. Similar to what I have done to patch the Windows Phone >>>> csproj. >>>> >>>> Regarding naming I agree with rob to stick to the current pattern like >>>> the 0.9.0.2110 example. I think it would be easiest if the >>>> Major.Minor.Patch part could become a TeamCity setting updated >>>> manually when we see fit. The build part would be supplied >>>> automatically after each build (suceeded or otherwise). The nice thing >>>> about TeamCity is that we can have it use that number to patch all >>>> AssembyInfo.cs files at once before build. >>>> >>>> So the build numbers would be 0.9.0.2110, 0.9.0.2111, 0.9.0.2112 and >>>> so on. Judging by your suggestions I understand that you would like >>>> the prerelease packages uploaded daily (provided anything changed)? My >>>> initial idea was to do that after each successful build by it may be >>>> an overkill. If so I think the the -nightly{yyMMdd} suffix is a good >>>> idea. >>>> >>>> To sum up we would have a single versioning pattern, and at moment of >>>> our choosing we would publish an official NuGet package: >>>> >>>> build 0.9.0.2112 => prerelease NuGet 0.9.0.2112-nightly130418 >>>> build 0.9.0.2115 => prerelease NuGet 0.9.0.2115-nightly130419 >>>> build 0.9.0.2116 => prerelease NuGet 0.9.0.2116-nightly130420 >>>> >>>> At this point we may decied that the last build was good enough and so >>>> the same version would be published as a stable NuGet package >>>> versioned without the prefix as simply 0.9.0.2116 and the main part >>>> could be bumped to 0.9.1. >>>> >>>> Thougths? >>>> >>>> Tom >>>> >>>> On Tue, Apr 16, 2013 at 6:14 PM, Rob Vesse <rv...@do...> >>>>wrote: >>>> > The build number can be used as part of the version string still, >>>> > currently >>>> > the Core library package uses version 0.9.0.2110 which works fine >>>> > >>>> > I like the notion of applying nightly{YYMMDD} as the pre-release >>>> > string, it >>>> > is nice and clean and does not involve having separate unstable >>>>packages >>>> > >>>> > The other thing we need to worry about is getting dependencies right >>>> > across >>>> > the packages since the Virtuoso and FullText libraries rely on the >>>>core >>>> > library. >>>> > >>>> > Rob >>>> > >>>> > From: Kal Ahmed <ka...@ne...> >>>> > Reply-To: dotNetRDF Developer Discussion and Feature Request >>>> > <dot...@li...> >>>> > Date: Tuesday, April 16, 2013 12:58 AM >>>> > To: dotNetRDF Developer Discussion and Feature Request >>>> > <dot...@li...> >>>> > Subject: Re: [dotNetRDF-Develop] NuGet Packaging >>>> > >>>> > Hi, >>>> > >>>> > One problem with NuGet versioning is that they have chopped off the >>>> > build >>>> > number, which means that if we have separate unstable packages we >>>> > potentially have issues in keeping the unstable package version and >>>>the >>>> > stable package version properly aligned. >>>> > >>>> > It looks like NuGets pre-release versioning uses the last string >>>>part of >>>> > the >>>> > package version to order packages from oldest to newest. So if we >>>>went >>>> > for >>>> > publishing pre-release versions we could use a scheme like >>>> > {maj}.{min}.{patch}-nightly{YYMMDD} e.g. 1.0.1-nightly130416. This >>>>way >>>> > all >>>> > nightly builds for a given release level stay in the correct order >>>>with >>>> > the >>>> > 1.0.1 release build being considered newer than all >>>>1.0.1-nightlyXXXXXX >>>> > builds. >>>> > >>>> > For those reasons, I think that to start with using NuGet pre-release >>>> > versioning makes sense - it still leaves us the option of introducing >>>> > "unstable" packages later. >>>> > >>>> > Cheers >>>> > >>>> > Kal >>>> > >>>> > >>>> > On Mon, Apr 15, 2013 at 10:07 PM, Rob Vesse <rv...@do...> >>>> > wrote: >>>> >> >>>> >> Hey All >>>> >> >>>> >> This email is part information sharing on how I currently package >>>>and >>>> >> upload dotNetRDF for NuGet but also to start a discussion on the >>>> >> possibility >>>> >> of making unstable builds available via NuGet which would make it >>>> >> easier for >>>> >> users to consume and verify bug fixes. >>>> >> >>>> >> Packaging >>>> >> >>>> >> Currently packaging is done via pre-build NuSpec files and NAnt >>>> >> targets. >>>> >> Under Build/nuget/ in the repo you will find a sub-directory for >>>>each >>>> >> package we produce. In a clean repo this will contain only a >>>>.nuspec >>>> >> file >>>> >> and possibly a readme.txt if the package requires one. >>>> >> >>>> >> To generate the NuGet packages use NAnt and one of the following >>>> >> targets: >>>> >> >>>> >> dist-libs-nuget Builds all the NuGet packages >>>> >> dist-libs-nuget-core Build the core library package >>>> >> dist-libs-nuget-data-virtuoso Build the Data.Virtuoso package >>>> >> dist-libs-nuget-query-fulltext Builds the Query.FullText package >>>> >> >>>> >> These targets rely on various other targets so will compile things >>>>as >>>> >> necessary. >>>> >> >>>> >> Uploading >>>> >> >>>> >> Uploading the releases is done via NAnt, the equivalent NAnt targets >>>> >> for >>>> >> the aforementioned targets simply replace dist with upload in the >>>> >> target >>>> >> name. >>>> >> >>>> >> Publishing Nightly Builds >>>> >> >>>> >> Tom has suggested that as part of getting our CI infrastructure >>>> >> properly >>>> >> spun up we should push out nightly builds to NuGet automatically. >>>> >> Currently >>>> >> the only means we have for distributing nighties is via the >>>> >> binaries-nightly >>>> >> repo we maintain at SourceForge which relies on a developer manually >>>> >> uploading a new build. >>>> >> >>>> >> The main barrier to this with NuGet as I understand it is that >>>>unlike >>>> >> Java/Maven where you can specify SNAPSHOT on the end of your version >>>> >> and >>>> >> have the server generate unique version numbers for you with NuGet >>>>you >>>> >> have >>>> >> to specify a unique version number each time. So we need some >>>> >> mechanism to >>>> >> inject version numbers into the nuspec files, NuGet does appear to >>>> >> support >>>> >> placeholders but we would need to test to make sure these work as >>>> >> described. >>>> >> We would also need to make sure that if we take this approach that >>>>we >>>> >> are >>>> >> using * in the build field of our AssemblyVersion attributes so >>>>that we >>>> >> get >>>> >> an incrementing version number. >>>> >> >>>> >> The other issue is where to publish these, we can either publish to >>>>a >>>> >> separate package ID which is explicitly described as >>>>Nightly/Unstable >>>> >> or we >>>> >> can publish unstable releases directly to the main feeds using the >>>> >> NuGet >>>> >> pre-release functionality >>>> >> >>>>(http://docs.nuget.org/docs/reference/versioning#Prerelease_Versions) >>>> >> >>>> >> There are arguments for both approaches: >>>> >> >>>> >> Separate package separates more cleanly from stable releases BUT >>>> >> introduces noise into NuGet search results unless we only publish >>>> >> pre-release builds to the unstable channel (pre-release builds are >>>> >> hidden by >>>> >> default from search results) >>>> >> Separate package allows us to have a package with more owners so any >>>> >> developer can publish to it, same package means expanding owner list >>>> >> Publishing pre-release versions avoids having to have separate >>>>packages >>>> >> for every package we have (currently 3) >>>> >> Publishing pre-release versions makes it easier for NuGet users to >>>> >> switch >>>> >> their dependency to the nightly build without changing their package >>>> >> dependencies. >>>> >> >>>> >> Thoughts and suggestions in this area are welcome, >>>> >> >>>> >> Rob >>>> >> >>>> >> >>>> >> >>>> >> >>>>------------------------------------------------------------------------ >>>>------ >>>> >> Precog is a next-generation analytics platform capable of advanced >>>> >> analytics on semi-structured data. The platform includes APIs for >>>> >> building >>>> >> apps and a phenomenal toolset for data science. Developers can use >>>> >> our toolset for easy data analysis & visualization. Get a free >>>>account! >>>> >> http://www2.precog.com/precogplatform/slashdotnewsletter >>>> >> _______________________________________________ >>>> >> dotNetRDF-develop mailing list >>>> >> dot...@li... >>>> >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Kal Ahmed >>>> > Director, Networked Planet Limited >>>> > e: kal...@ne... >>>> > w: www.networkedplanet.com >>>> > >>>> > >>>>------------------------------------------------------------------------ >>>>------ >>>> > Precog is a next-generation analytics platform capable of advanced >>>> > analytics >>>> > on semi-structured data. The platform includes APIs for building apps >>>> > and a >>>> > phenomenal toolset for data science. Developers can use our toolset >>>>for >>>> > easy >>>> > data analysis & visualization. Get a free account! >>>> > >>>> > >>>>http://www2.precog.com/precogplatform/slashdotnewsletter________________ >>>>_______________________________ >>>> > dotNetRDF-develop mailing list >>>>dot...@li... >>>> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>>> > >>>> > >>>> > >>>> > >>>>------------------------------------------------------------------------ >>>>------ >>>> > Precog is a next-generation analytics platform capable of advanced >>>> > analytics on semi-structured data. The platform includes APIs for >>>> > building >>>> > apps and a phenomenal toolset for data science. Developers can use >>>> > our toolset for easy data analysis & visualization. Get a free >>>>account! >>>> > http://www2.precog.com/precogplatform/slashdotnewsletter >>>> > _______________________________________________ >>>> > dotNetRDF-develop mailing list >>>> > dot...@li... >>>> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>>> > >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>>------ >>>> Precog is a next-generation analytics platform capable of advanced >>>> analytics on semi-structured data. The platform includes APIs for >>>>building >>>> apps and a phenomenal toolset for data science. Developers can use >>>> our toolset for easy data analysis & visualization. Get a free account! >>>> http://www2.precog.com/precogplatform/slashdotnewsletter >>>> _______________________________________________ >>>> dotNetRDF-develop mailing list >>>> dot...@li... >>>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>> >>> >>> >>> >>> -- >>> Kal Ahmed >>> Director, Networked Planet Limited >>> e: kal...@ne... >>> w: www.networkedplanet.com >>> >>> >>>------------------------------------------------------------------------- >>>----- >>> Precog is a next-generation analytics platform capable of advanced >>> analytics on semi-structured data. The platform includes APIs for >>>building >>> apps and a phenomenal toolset for data science. Developers can use >>> our toolset for easy data analysis & visualization. Get a free account! >>> http://www2.precog.com/precogplatform/slashdotnewsletter >>> _______________________________________________ >>> dotNetRDF-develop mailing list >>> dot...@li... >>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>> >> >>-------------------------------------------------------------------------- >>---- >>Precog is a next-generation analytics platform capable of advanced >>analytics on semi-structured data. The platform includes APIs for building >>apps and a phenomenal toolset for data science. Developers can use >>our toolset for easy data analysis & visualization. Get a free account! >>http://www2.precog.com/precogplatform/slashdotnewsletter >>_______________________________________________ >>dotNetRDF-develop mailing list >>dot...@li... >>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
From: <tr...@do...> - 2013-04-19 21:21:33
|
<p>The following issue has been updated by Rob Vesse:</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support a ReadWrite variant of SparqlConnector that uses SPARQL Update for write operations</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td colspan="2"><b>Changes:</b></td> </tr> <tr> <td colspan="2"> <ul> <li>Milestone changed from "1.0.1" to "1.0.0" </li> <li>Assigned to changed from "Unassigned" to "none" </li> </ul> </td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-19 21:21:22
|
<p>A new comment has been added to the following issue.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support a ReadWrite variant of SparqlConnector that uses SPARQL Update for write operations</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Rob Vesse</td> </tr> <tr> <td><b>Date:</b></td> <td>2013-04-19 10:20 PM</td> </tr> <tr> <td><b>Comment:</b></td> </tr> <tr> <td colspan="2"><p> Push up to 1.0.0 since 1.0.0 will be delayed for a couple more weeks to finish some other stuff which gives more time for testing</p></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-19 21:20:41
|
<p>The following issue has been updated by Rob Vesse:</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Upgrade support for Turtle 1.1 and TriG to latest drafts</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td colspan="2"><b>Changes:</b></td> </tr> <tr> <td colspan="2"> <ul> <li>Milestone changed from "1.0.1" to "1.0.0" </li> </ul> </td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=314" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=314</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-19 21:19:58
|
<p>A new comment has been added to the following issue.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support configurable culture for parsing and serializing literals</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Rob Vesse</td> </tr> <tr> <td><b>Date:</b></td> <td>2013-04-19 10:19 PM</td> </tr> <tr> <td><b>Comment:</b></td> </tr> <tr> <td colspan="2"><p> Moving to unscheduled since I'm not sure this is a wise feature to add</p></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=316" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=316</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: Rob V. <rv...@do...> - 2013-04-19 21:18:15
|
Hey All I was originally going to try and push out 1.0.0 but I have decided to delay by another week or two to try and get some extra stuff done. In particular some of the stuff in the CORE-314 branch (latest Turtle spec support) highlighted another error in GraphMatcher and some general bugs in Turtle parsing beyond those related to meeting the latest spec. I have code in that branch passing the bulk of the tests (259 passed, 14 failed, 15 indeterminate) and nothing fails fatally (I.e. stack traces) right now so it's already in fairly good shape. I will likely merge what I have so far to default anyway since it improves Turtle support even if it isn't yet perfect and fixes the aforementioned issues. There is also the CORE-346 branch which has a new ReadWriteSparqlConnector which is the update capable version of SparqlConnector which is stable and passing the new tests I wrote for it. I would also like to at least look at CORE-349 (a bug with * in property paths) in case there is a trivial fix there. Anything else small and self contained that people would like to get into 1.0.0 if they can? Rob |
From: Rob V. <rv...@do...> - 2013-04-19 21:10:57
|
Why can't we use the local HG numeric revision? While this isn't unique across clones if we have a single build server responsible for builds that should be irrelevant since it will always increment on that server Rob On 4/19/13 3:50 AM, "Tomasz Pluskiewicz" <tom...@gm...> wrote: >Kal, > >Oh I see. I think I slightly misunderstood the prerelease feature > >So maybe let's do it this way. The current stable release is >0.9.0.2110 and the upcoming is 1.0.0. This means that the automatic >builds would be named > >1.0.0-prerelase2111 >1.0.0-prerelase2112 >1.0.0-prerelase2113 > >and the stable would be just 1.0.0.2114 or simply 1.0.0 at which point >it will be bumped to 1.0.1 for the next batch of prerelease. Would >that be more like whet SemVer is about? > >Regarding tracing back a build to HG revisions. There are some ways. >One would be to include the commit hash in version string (not good >IMO). There's also the VCS labelling feature in TeamCity. I just got >it create a tag in my test repo [1]. The downside is there will be a >swathe of tags but it's super easy to remove tags from time to time as >a cleanup task. > >Tom > >[1]: >https://bitbucket.org/tpluscode/dotnetrdf-teamcity/commits/c1f1ac2c6ab242d >3d104e920b33718a89b2280b5 > >On Fri, Apr 19, 2013 at 10:55 AM, Khalil Ahmed <ka...@ne...> >wrote: >> Hi Tom, >> >> All looks fine to me. Though just to be clear this approach is >>basically not >> making use of the prerelease versioning functionality of NuGet, because >> prerelease versioning in nuget is based on the value after the dash. It >>all >> works nicely though as NuGet will treat a stable 0.9.0.2116 release as >>later >> than a pre-release 0.9.0.2116-nightly130420 release. >> >> Will there be some way to tie build number back to some state of the Hg >> repository ? >> >> Cheers >> >> Kal >> >> >> On Thu, Apr 18, 2013 at 10:11 PM, Tomasz Pluskiewicz >> <tom...@gm...> wrote: >>> >>> Hi >>> >>> There is one other way to proceed with unstable NuGet packages. We can >>> set up TeamCity as a package repository. The downside is that we would >>> have to require users to modify their setup. Having said that I'm too >>> in favour of using the prerelease feature and having only one package >>> stream. In fact I'd forgotten that feature exists. >>> >>> Unfortunately Rob's right and we will need to ensure correct >>> dependencies but it should be fairly easy to achieve using the <style> >>> target of NAnt. Similar to what I have done to patch the Windows Phone >>> csproj. >>> >>> Regarding naming I agree with rob to stick to the current pattern like >>> the 0.9.0.2110 example. I think it would be easiest if the >>> Major.Minor.Patch part could become a TeamCity setting updated >>> manually when we see fit. The build part would be supplied >>> automatically after each build (suceeded or otherwise). The nice thing >>> about TeamCity is that we can have it use that number to patch all >>> AssembyInfo.cs files at once before build. >>> >>> So the build numbers would be 0.9.0.2110, 0.9.0.2111, 0.9.0.2112 and >>> so on. Judging by your suggestions I understand that you would like >>> the prerelease packages uploaded daily (provided anything changed)? My >>> initial idea was to do that after each successful build by it may be >>> an overkill. If so I think the the -nightly{yyMMdd} suffix is a good >>> idea. >>> >>> To sum up we would have a single versioning pattern, and at moment of >>> our choosing we would publish an official NuGet package: >>> >>> build 0.9.0.2112 => prerelease NuGet 0.9.0.2112-nightly130418 >>> build 0.9.0.2115 => prerelease NuGet 0.9.0.2115-nightly130419 >>> build 0.9.0.2116 => prerelease NuGet 0.9.0.2116-nightly130420 >>> >>> At this point we may decied that the last build was good enough and so >>> the same version would be published as a stable NuGet package >>> versioned without the prefix as simply 0.9.0.2116 and the main part >>> could be bumped to 0.9.1. >>> >>> Thougths? >>> >>> Tom >>> >>> On Tue, Apr 16, 2013 at 6:14 PM, Rob Vesse <rv...@do...> >>>wrote: >>> > The build number can be used as part of the version string still, >>> > currently >>> > the Core library package uses version 0.9.0.2110 which works fine >>> > >>> > I like the notion of applying nightly{YYMMDD} as the pre-release >>> > string, it >>> > is nice and clean and does not involve having separate unstable >>>packages >>> > >>> > The other thing we need to worry about is getting dependencies right >>> > across >>> > the packages since the Virtuoso and FullText libraries rely on the >>>core >>> > library. >>> > >>> > Rob >>> > >>> > From: Kal Ahmed <ka...@ne...> >>> > Reply-To: dotNetRDF Developer Discussion and Feature Request >>> > <dot...@li...> >>> > Date: Tuesday, April 16, 2013 12:58 AM >>> > To: dotNetRDF Developer Discussion and Feature Request >>> > <dot...@li...> >>> > Subject: Re: [dotNetRDF-Develop] NuGet Packaging >>> > >>> > Hi, >>> > >>> > One problem with NuGet versioning is that they have chopped off the >>> > build >>> > number, which means that if we have separate unstable packages we >>> > potentially have issues in keeping the unstable package version and >>>the >>> > stable package version properly aligned. >>> > >>> > It looks like NuGets pre-release versioning uses the last string >>>part of >>> > the >>> > package version to order packages from oldest to newest. So if we >>>went >>> > for >>> > publishing pre-release versions we could use a scheme like >>> > {maj}.{min}.{patch}-nightly{YYMMDD} e.g. 1.0.1-nightly130416. This >>>way >>> > all >>> > nightly builds for a given release level stay in the correct order >>>with >>> > the >>> > 1.0.1 release build being considered newer than all >>>1.0.1-nightlyXXXXXX >>> > builds. >>> > >>> > For those reasons, I think that to start with using NuGet pre-release >>> > versioning makes sense - it still leaves us the option of introducing >>> > "unstable" packages later. >>> > >>> > Cheers >>> > >>> > Kal >>> > >>> > >>> > On Mon, Apr 15, 2013 at 10:07 PM, Rob Vesse <rv...@do...> >>> > wrote: >>> >> >>> >> Hey All >>> >> >>> >> This email is part information sharing on how I currently package >>>and >>> >> upload dotNetRDF for NuGet but also to start a discussion on the >>> >> possibility >>> >> of making unstable builds available via NuGet which would make it >>> >> easier for >>> >> users to consume and verify bug fixes. >>> >> >>> >> Packaging >>> >> >>> >> Currently packaging is done via pre-build NuSpec files and NAnt >>> >> targets. >>> >> Under Build/nuget/ in the repo you will find a sub-directory for >>>each >>> >> package we produce. In a clean repo this will contain only a >>>.nuspec >>> >> file >>> >> and possibly a readme.txt if the package requires one. >>> >> >>> >> To generate the NuGet packages use NAnt and one of the following >>> >> targets: >>> >> >>> >> dist-libs-nuget Builds all the NuGet packages >>> >> dist-libs-nuget-core Build the core library package >>> >> dist-libs-nuget-data-virtuoso Build the Data.Virtuoso package >>> >> dist-libs-nuget-query-fulltext Builds the Query.FullText package >>> >> >>> >> These targets rely on various other targets so will compile things >>>as >>> >> necessary. >>> >> >>> >> Uploading >>> >> >>> >> Uploading the releases is done via NAnt, the equivalent NAnt targets >>> >> for >>> >> the aforementioned targets simply replace dist with upload in the >>> >> target >>> >> name. >>> >> >>> >> Publishing Nightly Builds >>> >> >>> >> Tom has suggested that as part of getting our CI infrastructure >>> >> properly >>> >> spun up we should push out nightly builds to NuGet automatically. >>> >> Currently >>> >> the only means we have for distributing nighties is via the >>> >> binaries-nightly >>> >> repo we maintain at SourceForge which relies on a developer manually >>> >> uploading a new build. >>> >> >>> >> The main barrier to this with NuGet as I understand it is that >>>unlike >>> >> Java/Maven where you can specify SNAPSHOT on the end of your version >>> >> and >>> >> have the server generate unique version numbers for you with NuGet >>>you >>> >> have >>> >> to specify a unique version number each time. So we need some >>> >> mechanism to >>> >> inject version numbers into the nuspec files, NuGet does appear to >>> >> support >>> >> placeholders but we would need to test to make sure these work as >>> >> described. >>> >> We would also need to make sure that if we take this approach that >>>we >>> >> are >>> >> using * in the build field of our AssemblyVersion attributes so >>>that we >>> >> get >>> >> an incrementing version number. >>> >> >>> >> The other issue is where to publish these, we can either publish to >>>a >>> >> separate package ID which is explicitly described as >>>Nightly/Unstable >>> >> or we >>> >> can publish unstable releases directly to the main feeds using the >>> >> NuGet >>> >> pre-release functionality >>> >> >>>(http://docs.nuget.org/docs/reference/versioning#Prerelease_Versions) >>> >> >>> >> There are arguments for both approaches: >>> >> >>> >> Separate package separates more cleanly from stable releases BUT >>> >> introduces noise into NuGet search results unless we only publish >>> >> pre-release builds to the unstable channel (pre-release builds are >>> >> hidden by >>> >> default from search results) >>> >> Separate package allows us to have a package with more owners so any >>> >> developer can publish to it, same package means expanding owner list >>> >> Publishing pre-release versions avoids having to have separate >>>packages >>> >> for every package we have (currently 3) >>> >> Publishing pre-release versions makes it easier for NuGet users to >>> >> switch >>> >> their dependency to the nightly build without changing their package >>> >> dependencies. >>> >> >>> >> Thoughts and suggestions in this area are welcome, >>> >> >>> >> Rob >>> >> >>> >> >>> >> >>> >> >>>------------------------------------------------------------------------ >>>------ >>> >> Precog is a next-generation analytics platform capable of advanced >>> >> analytics on semi-structured data. The platform includes APIs for >>> >> building >>> >> apps and a phenomenal toolset for data science. Developers can use >>> >> our toolset for easy data analysis & visualization. Get a free >>>account! >>> >> http://www2.precog.com/precogplatform/slashdotnewsletter >>> >> _______________________________________________ >>> >> dotNetRDF-develop mailing list >>> >> dot...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>> >> >>> > >>> > >>> > >>> > -- >>> > Kal Ahmed >>> > Director, Networked Planet Limited >>> > e: kal...@ne... >>> > w: www.networkedplanet.com >>> > >>> > >>>------------------------------------------------------------------------ >>>------ >>> > Precog is a next-generation analytics platform capable of advanced >>> > analytics >>> > on semi-structured data. The platform includes APIs for building apps >>> > and a >>> > phenomenal toolset for data science. Developers can use our toolset >>>for >>> > easy >>> > data analysis & visualization. Get a free account! >>> > >>> > >>>http://www2.precog.com/precogplatform/slashdotnewsletter________________ >>>_______________________________ >>> > dotNetRDF-develop mailing list >>>dot...@li... >>> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>> > >>> > >>> > >>> > >>>------------------------------------------------------------------------ >>>------ >>> > Precog is a next-generation analytics platform capable of advanced >>> > analytics on semi-structured data. The platform includes APIs for >>> > building >>> > apps and a phenomenal toolset for data science. Developers can use >>> > our toolset for easy data analysis & visualization. Get a free >>>account! >>> > http://www2.precog.com/precogplatform/slashdotnewsletter >>> > _______________________________________________ >>> > dotNetRDF-develop mailing list >>> > dot...@li... >>> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >>> > >>> >>> >>> >>>------------------------------------------------------------------------ >>>------ >>> Precog is a next-generation analytics platform capable of advanced >>> analytics on semi-structured data. The platform includes APIs for >>>building >>> apps and a phenomenal toolset for data science. Developers can use >>> our toolset for easy data analysis & visualization. Get a free account! >>> http://www2.precog.com/precogplatform/slashdotnewsletter >>> _______________________________________________ >>> dotNetRDF-develop mailing list >>> dot...@li... >>> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> >> >> >> >> -- >> Kal Ahmed >> Director, Networked Planet Limited >> e: kal...@ne... >> w: www.networkedplanet.com >> >> >>------------------------------------------------------------------------- >>----- >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for >>building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> > >-------------------------------------------------------------------------- >---- >Precog is a next-generation analytics platform capable of advanced >analytics on semi-structured data. The platform includes APIs for building >apps and a phenomenal toolset for data science. Developers can use >our toolset for easy data analysis & visualization. Get a free account! >http://www2.precog.com/precogplatform/slashdotnewsletter >_______________________________________________ >dotNetRDF-develop mailing list >dot...@li... >https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop |
From: Tomasz P. <tom...@gm...> - 2013-04-19 10:51:04
|
Kal, Oh I see. I think I slightly misunderstood the prerelease feature So maybe let's do it this way. The current stable release is 0.9.0.2110 and the upcoming is 1.0.0. This means that the automatic builds would be named 1.0.0-prerelase2111 1.0.0-prerelase2112 1.0.0-prerelase2113 and the stable would be just 1.0.0.2114 or simply 1.0.0 at which point it will be bumped to 1.0.1 for the next batch of prerelease. Would that be more like whet SemVer is about? Regarding tracing back a build to HG revisions. There are some ways. One would be to include the commit hash in version string (not good IMO). There's also the VCS labelling feature in TeamCity. I just got it create a tag in my test repo [1]. The downside is there will be a swathe of tags but it's super easy to remove tags from time to time as a cleanup task. Tom [1]: https://bitbucket.org/tpluscode/dotnetrdf-teamcity/commits/c1f1ac2c6ab242d3d104e920b33718a89b2280b5 On Fri, Apr 19, 2013 at 10:55 AM, Khalil Ahmed <ka...@ne...> wrote: > Hi Tom, > > All looks fine to me. Though just to be clear this approach is basically not > making use of the prerelease versioning functionality of NuGet, because > prerelease versioning in nuget is based on the value after the dash. It all > works nicely though as NuGet will treat a stable 0.9.0.2116 release as later > than a pre-release 0.9.0.2116-nightly130420 release. > > Will there be some way to tie build number back to some state of the Hg > repository ? > > Cheers > > Kal > > > On Thu, Apr 18, 2013 at 10:11 PM, Tomasz Pluskiewicz > <tom...@gm...> wrote: >> >> Hi >> >> There is one other way to proceed with unstable NuGet packages. We can >> set up TeamCity as a package repository. The downside is that we would >> have to require users to modify their setup. Having said that I'm too >> in favour of using the prerelease feature and having only one package >> stream. In fact I'd forgotten that feature exists. >> >> Unfortunately Rob's right and we will need to ensure correct >> dependencies but it should be fairly easy to achieve using the <style> >> target of NAnt. Similar to what I have done to patch the Windows Phone >> csproj. >> >> Regarding naming I agree with rob to stick to the current pattern like >> the 0.9.0.2110 example. I think it would be easiest if the >> Major.Minor.Patch part could become a TeamCity setting updated >> manually when we see fit. The build part would be supplied >> automatically after each build (suceeded or otherwise). The nice thing >> about TeamCity is that we can have it use that number to patch all >> AssembyInfo.cs files at once before build. >> >> So the build numbers would be 0.9.0.2110, 0.9.0.2111, 0.9.0.2112 and >> so on. Judging by your suggestions I understand that you would like >> the prerelease packages uploaded daily (provided anything changed)? My >> initial idea was to do that after each successful build by it may be >> an overkill. If so I think the the -nightly{yyMMdd} suffix is a good >> idea. >> >> To sum up we would have a single versioning pattern, and at moment of >> our choosing we would publish an official NuGet package: >> >> build 0.9.0.2112 => prerelease NuGet 0.9.0.2112-nightly130418 >> build 0.9.0.2115 => prerelease NuGet 0.9.0.2115-nightly130419 >> build 0.9.0.2116 => prerelease NuGet 0.9.0.2116-nightly130420 >> >> At this point we may decied that the last build was good enough and so >> the same version would be published as a stable NuGet package >> versioned without the prefix as simply 0.9.0.2116 and the main part >> could be bumped to 0.9.1. >> >> Thougths? >> >> Tom >> >> On Tue, Apr 16, 2013 at 6:14 PM, Rob Vesse <rv...@do...> wrote: >> > The build number can be used as part of the version string still, >> > currently >> > the Core library package uses version 0.9.0.2110 which works fine >> > >> > I like the notion of applying –nightly{YYMMDD} as the pre-release >> > string, it >> > is nice and clean and does not involve having separate unstable packages >> > >> > The other thing we need to worry about is getting dependencies right >> > across >> > the packages since the Virtuoso and FullText libraries rely on the core >> > library. >> > >> > Rob >> > >> > From: Kal Ahmed <ka...@ne...> >> > Reply-To: dotNetRDF Developer Discussion and Feature Request >> > <dot...@li...> >> > Date: Tuesday, April 16, 2013 12:58 AM >> > To: dotNetRDF Developer Discussion and Feature Request >> > <dot...@li...> >> > Subject: Re: [dotNetRDF-Develop] NuGet Packaging >> > >> > Hi, >> > >> > One problem with NuGet versioning is that they have chopped off the >> > build >> > number, which means that if we have separate unstable packages we >> > potentially have issues in keeping the unstable package version and the >> > stable package version properly aligned. >> > >> > It looks like NuGets pre-release versioning uses the last string part of >> > the >> > package version to order packages from oldest to newest. So if we went >> > for >> > publishing pre-release versions we could use a scheme like >> > {maj}.{min}.{patch}-nightly{YYMMDD} e.g. 1.0.1-nightly130416. This way >> > all >> > nightly builds for a given release level stay in the correct order with >> > the >> > 1.0.1 release build being considered newer than all 1.0.1-nightlyXXXXXX >> > builds. >> > >> > For those reasons, I think that to start with using NuGet pre-release >> > versioning makes sense - it still leaves us the option of introducing >> > "unstable" packages later. >> > >> > Cheers >> > >> > Kal >> > >> > >> > On Mon, Apr 15, 2013 at 10:07 PM, Rob Vesse <rv...@do...> >> > wrote: >> >> >> >> Hey All >> >> >> >> This email is part information sharing on how I currently package and >> >> upload dotNetRDF for NuGet but also to start a discussion on the >> >> possibility >> >> of making unstable builds available via NuGet which would make it >> >> easier for >> >> users to consume and verify bug fixes. >> >> >> >> Packaging >> >> >> >> Currently packaging is done via pre-build NuSpec files and NAnt >> >> targets. >> >> Under Build/nuget/ in the repo you will find a sub-directory for each >> >> package we produce. In a clean repo this will contain only a .nuspec >> >> file >> >> and possibly a readme.txt if the package requires one. >> >> >> >> To generate the NuGet packages use NAnt and one of the following >> >> targets: >> >> >> >> dist-libs-nuget – Builds all the NuGet packages >> >> dist-libs-nuget-core – Build the core library package >> >> dist-libs-nuget-data-virtuoso – Build the Data.Virtuoso package >> >> dist-libs-nuget-query-fulltext – Builds the Query.FullText package >> >> >> >> These targets rely on various other targets so will compile things as >> >> necessary. >> >> >> >> Uploading >> >> >> >> Uploading the releases is done via NAnt, the equivalent NAnt targets >> >> for >> >> the aforementioned targets simply replace dist with upload in the >> >> target >> >> name. >> >> >> >> Publishing Nightly Builds >> >> >> >> Tom has suggested that as part of getting our CI infrastructure >> >> properly >> >> spun up we should push out nightly builds to NuGet automatically. >> >> Currently >> >> the only means we have for distributing nighties is via the >> >> binaries-nightly >> >> repo we maintain at SourceForge which relies on a developer manually >> >> uploading a new build. >> >> >> >> The main barrier to this with NuGet as I understand it is that unlike >> >> Java/Maven where you can specify SNAPSHOT on the end of your version >> >> and >> >> have the server generate unique version numbers for you with NuGet you >> >> have >> >> to specify a unique version number each time. So we need some >> >> mechanism to >> >> inject version numbers into the nuspec files, NuGet does appear to >> >> support >> >> placeholders but we would need to test to make sure these work as >> >> described. >> >> We would also need to make sure that if we take this approach that we >> >> are >> >> using * in the build field of our AssemblyVersion attributes so that we >> >> get >> >> an incrementing version number. >> >> >> >> The other issue is where to publish these, we can either publish to a >> >> separate package ID which is explicitly described as Nightly/Unstable >> >> or we >> >> can publish unstable releases directly to the main feeds using the >> >> NuGet >> >> pre-release functionality >> >> (http://docs.nuget.org/docs/reference/versioning#Prerelease_Versions) >> >> >> >> There are arguments for both approaches: >> >> >> >> Separate package separates more cleanly from stable releases BUT >> >> introduces noise into NuGet search results unless we only publish >> >> pre-release builds to the unstable channel (pre-release builds are >> >> hidden by >> >> default from search results) >> >> Separate package allows us to have a package with more owners so any >> >> developer can publish to it, same package means expanding owner list >> >> Publishing pre-release versions avoids having to have separate packages >> >> for every package we have (currently 3) >> >> Publishing pre-release versions makes it easier for NuGet users to >> >> switch >> >> their dependency to the nightly build without changing their package >> >> dependencies. >> >> >> >> Thoughts and suggestions in this area are welcome, >> >> >> >> Rob >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Precog is a next-generation analytics platform capable of advanced >> >> analytics on semi-structured data. The platform includes APIs for >> >> building >> >> apps and a phenomenal toolset for data science. Developers can use >> >> our toolset for easy data analysis & visualization. Get a free account! >> >> http://www2.precog.com/precogplatform/slashdotnewsletter >> >> _______________________________________________ >> >> dotNetRDF-develop mailing list >> >> dot...@li... >> >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> >> >> > >> > >> > >> > -- >> > Kal Ahmed >> > Director, Networked Planet Limited >> > e: kal...@ne... >> > w: www.networkedplanet.com >> > >> > ------------------------------------------------------------------------------ >> > Precog is a next-generation analytics platform capable of advanced >> > analytics >> > on semi-structured data. The platform includes APIs for building apps >> > and a >> > phenomenal toolset for data science. Developers can use our toolset for >> > easy >> > data analysis & visualization. Get a free account! >> > >> > http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________ >> > dotNetRDF-develop mailing list dot...@li... >> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Precog is a next-generation analytics platform capable of advanced >> > analytics on semi-structured data. The platform includes APIs for >> > building >> > apps and a phenomenal toolset for data science. Developers can use >> > our toolset for easy data analysis & visualization. Get a free account! >> > http://www2.precog.com/precogplatform/slashdotnewsletter >> > _______________________________________________ >> > dotNetRDF-develop mailing list >> > dot...@li... >> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> > >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > > > -- > Kal Ahmed > Director, Networked Planet Limited > e: kal...@ne... > w: www.networkedplanet.com > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > |
From: Khalil A. <ka...@ne...> - 2013-04-19 08:55:31
|
Hi Tom, All looks fine to me. Though just to be clear this approach is basically not making use of the prerelease versioning functionality of NuGet, because prerelease versioning in nuget is based on the value after the dash. It all works nicely though as NuGet will treat a stable 0.9.0.2116 release as later than a pre-release 0.9.0.2116-nightly130420 release. Will there be some way to tie build number back to some state of the Hg repository ? Cheers Kal On Thu, Apr 18, 2013 at 10:11 PM, Tomasz Pluskiewicz < tom...@gm...> wrote: > Hi > > There is one other way to proceed with unstable NuGet packages. We can > set up TeamCity as a package repository. The downside is that we would > have to require users to modify their setup. Having said that I'm too > in favour of using the prerelease feature and having only one package > stream. In fact I'd forgotten that feature exists. > > Unfortunately Rob's right and we will need to ensure correct > dependencies but it should be fairly easy to achieve using the <style> > target of NAnt. Similar to what I have done to patch the Windows Phone > csproj. > > Regarding naming I agree with rob to stick to the current pattern like > the 0.9.0.2110 example. I think it would be easiest if the > Major.Minor.Patch part could become a TeamCity setting updated > manually when we see fit. The build part would be supplied > automatically after each build (suceeded or otherwise). The nice thing > about TeamCity is that we can have it use that number to patch all > AssembyInfo.cs files at once before build. > > So the build numbers would be 0.9.0.2110, 0.9.0.2111, 0.9.0.2112 and > so on. Judging by your suggestions I understand that you would like > the prerelease packages uploaded daily (provided anything changed)? My > initial idea was to do that after each successful build by it may be > an overkill. If so I think the the -nightly{yyMMdd} suffix is a good > idea. > > To sum up we would have a single versioning pattern, and at moment of > our choosing we would publish an official NuGet package: > > build 0.9.0.2112 => prerelease NuGet 0.9.0.2112-nightly130418 > build 0.9.0.2115 => prerelease NuGet 0.9.0.2115-nightly130419 > build 0.9.0.2116 => prerelease NuGet 0.9.0.2116-nightly130420 > > At this point we may decied that the last build was good enough and so > the same version would be published as a stable NuGet package > versioned without the prefix as simply 0.9.0.2116 and the main part > could be bumped to 0.9.1. > > Thougths? > > Tom > > On Tue, Apr 16, 2013 at 6:14 PM, Rob Vesse <rv...@do...> wrote: > > The build number can be used as part of the version string still, > currently > > the Core library package uses version 0.9.0.2110 which works fine > > > > I like the notion of applying –nightly{YYMMDD} as the pre-release > string, it > > is nice and clean and does not involve having separate unstable packages > > > > The other thing we need to worry about is getting dependencies right > across > > the packages since the Virtuoso and FullText libraries rely on the core > > library. > > > > Rob > > > > From: Kal Ahmed <ka...@ne...> > > Reply-To: dotNetRDF Developer Discussion and Feature Request > > <dot...@li...> > > Date: Tuesday, April 16, 2013 12:58 AM > > To: dotNetRDF Developer Discussion and Feature Request > > <dot...@li...> > > Subject: Re: [dotNetRDF-Develop] NuGet Packaging > > > > Hi, > > > > One problem with NuGet versioning is that they have chopped off the build > > number, which means that if we have separate unstable packages we > > potentially have issues in keeping the unstable package version and the > > stable package version properly aligned. > > > > It looks like NuGets pre-release versioning uses the last string part of > the > > package version to order packages from oldest to newest. So if we went > for > > publishing pre-release versions we could use a scheme like > > {maj}.{min}.{patch}-nightly{YYMMDD} e.g. 1.0.1-nightly130416. This way > all > > nightly builds for a given release level stay in the correct order with > the > > 1.0.1 release build being considered newer than all 1.0.1-nightlyXXXXXX > > builds. > > > > For those reasons, I think that to start with using NuGet pre-release > > versioning makes sense - it still leaves us the option of introducing > > "unstable" packages later. > > > > Cheers > > > > Kal > > > > > > On Mon, Apr 15, 2013 at 10:07 PM, Rob Vesse <rv...@do...> > wrote: > >> > >> Hey All > >> > >> This email is part information sharing on how I currently package and > >> upload dotNetRDF for NuGet but also to start a discussion on the > possibility > >> of making unstable builds available via NuGet which would make it > easier for > >> users to consume and verify bug fixes. > >> > >> Packaging > >> > >> Currently packaging is done via pre-build NuSpec files and NAnt targets. > >> Under Build/nuget/ in the repo you will find a sub-directory for each > >> package we produce. In a clean repo this will contain only a .nuspec > file > >> and possibly a readme.txt if the package requires one. > >> > >> To generate the NuGet packages use NAnt and one of the following > targets: > >> > >> dist-libs-nuget – Builds all the NuGet packages > >> dist-libs-nuget-core – Build the core library package > >> dist-libs-nuget-data-virtuoso – Build the Data.Virtuoso package > >> dist-libs-nuget-query-fulltext – Builds the Query.FullText package > >> > >> These targets rely on various other targets so will compile things as > >> necessary. > >> > >> Uploading > >> > >> Uploading the releases is done via NAnt, the equivalent NAnt targets for > >> the aforementioned targets simply replace dist with upload in the target > >> name. > >> > >> Publishing Nightly Builds > >> > >> Tom has suggested that as part of getting our CI infrastructure properly > >> spun up we should push out nightly builds to NuGet automatically. > Currently > >> the only means we have for distributing nighties is via the > binaries-nightly > >> repo we maintain at SourceForge which relies on a developer manually > >> uploading a new build. > >> > >> The main barrier to this with NuGet as I understand it is that unlike > >> Java/Maven where you can specify SNAPSHOT on the end of your version and > >> have the server generate unique version numbers for you with NuGet you > have > >> to specify a unique version number each time. So we need some > mechanism to > >> inject version numbers into the nuspec files, NuGet does appear to > support > >> placeholders but we would need to test to make sure these work as > described. > >> We would also need to make sure that if we take this approach that we > are > >> using * in the build field of our AssemblyVersion attributes so that we > get > >> an incrementing version number. > >> > >> The other issue is where to publish these, we can either publish to a > >> separate package ID which is explicitly described as Nightly/Unstable > or we > >> can publish unstable releases directly to the main feeds using the NuGet > >> pre-release functionality > >> (http://docs.nuget.org/docs/reference/versioning#Prerelease_Versions) > >> > >> There are arguments for both approaches: > >> > >> Separate package separates more cleanly from stable releases BUT > >> introduces noise into NuGet search results unless we only publish > >> pre-release builds to the unstable channel (pre-release builds are > hidden by > >> default from search results) > >> Separate package allows us to have a package with more owners so any > >> developer can publish to it, same package means expanding owner list > >> Publishing pre-release versions avoids having to have separate packages > >> for every package we have (currently 3) > >> Publishing pre-release versions makes it easier for NuGet users to > switch > >> their dependency to the nightly build without changing their package > >> dependencies. > >> > >> Thoughts and suggestions in this area are welcome, > >> > >> Rob > >> > >> > >> > ------------------------------------------------------------------------------ > >> Precog is a next-generation analytics platform capable of advanced > >> analytics on semi-structured data. The platform includes APIs for > building > >> apps and a phenomenal toolset for data science. Developers can use > >> our toolset for easy data analysis & visualization. Get a free account! > >> http://www2.precog.com/precogplatform/slashdotnewsletter > >> _______________________________________________ > >> dotNetRDF-develop mailing list > >> dot...@li... > >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > >> > > > > > > > > -- > > Kal Ahmed > > Director, Networked Planet Limited > > e: kal...@ne... > > w: www.networkedplanet.com > > > ------------------------------------------------------------------------------ > > Precog is a next-generation analytics platform capable of advanced > analytics > > on semi-structured data. The platform includes APIs for building apps > and a > > phenomenal toolset for data science. Developers can use our toolset for > easy > > data analysis & visualization. Get a free account! > > > http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________ > > dotNetRDF-develop mailing list dot...@li... > > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > > > > > ------------------------------------------------------------------------------ > > Precog is a next-generation analytics platform capable of advanced > > analytics on semi-structured data. The platform includes APIs for > building > > apps and a phenomenal toolset for data science. Developers can use > > our toolset for easy data analysis & visualization. Get a free account! > > http://www2.precog.com/precogplatform/slashdotnewsletter > > _______________________________________________ > > dotNetRDF-develop mailing list > > dot...@li... > > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > -- Kal Ahmed Director, Networked Planet Limited e: kal...@ne... w: www.networkedplanet.com |
From: <tr...@do...> - 2013-04-18 23:11:32
|
<p>A new comment has been added to the following issue.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Upgrade support for Turtle 1.1 and TriG to latest drafts</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Rob Vesse</td> </tr> <tr> <td><b>Date:</b></td> <td>2013-04-19 12:10 AM</td> </tr> <tr> <td><b>Comment:</b></td> </tr> <tr> <td colspan="2"><p> Made a lot of progress on that, on the Turtle 1.1 suite we have 14 failures (results not as expected) and 15 indeterminate (expected results unloadable)</p> <p> This work has highlighted a number of bugs in the handling of UTF-32 codepoints which should now be addressed for Turtle parsing</p></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=314" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=314</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: Tomasz P. <tom...@gm...> - 2013-04-18 21:12:11
|
Hi There is one other way to proceed with unstable NuGet packages. We can set up TeamCity as a package repository. The downside is that we would have to require users to modify their setup. Having said that I'm too in favour of using the prerelease feature and having only one package stream. In fact I'd forgotten that feature exists. Unfortunately Rob's right and we will need to ensure correct dependencies but it should be fairly easy to achieve using the <style> target of NAnt. Similar to what I have done to patch the Windows Phone csproj. Regarding naming I agree with rob to stick to the current pattern like the 0.9.0.2110 example. I think it would be easiest if the Major.Minor.Patch part could become a TeamCity setting updated manually when we see fit. The build part would be supplied automatically after each build (suceeded or otherwise). The nice thing about TeamCity is that we can have it use that number to patch all AssembyInfo.cs files at once before build. So the build numbers would be 0.9.0.2110, 0.9.0.2111, 0.9.0.2112 and so on. Judging by your suggestions I understand that you would like the prerelease packages uploaded daily (provided anything changed)? My initial idea was to do that after each successful build by it may be an overkill. If so I think the the -nightly{yyMMdd} suffix is a good idea. To sum up we would have a single versioning pattern, and at moment of our choosing we would publish an official NuGet package: build 0.9.0.2112 => prerelease NuGet 0.9.0.2112-nightly130418 build 0.9.0.2115 => prerelease NuGet 0.9.0.2115-nightly130419 build 0.9.0.2116 => prerelease NuGet 0.9.0.2116-nightly130420 At this point we may decied that the last build was good enough and so the same version would be published as a stable NuGet package versioned without the prefix as simply 0.9.0.2116 and the main part could be bumped to 0.9.1. Thougths? Tom On Tue, Apr 16, 2013 at 6:14 PM, Rob Vesse <rv...@do...> wrote: > The build number can be used as part of the version string still, currently > the Core library package uses version 0.9.0.2110 which works fine > > I like the notion of applying –nightly{YYMMDD} as the pre-release string, it > is nice and clean and does not involve having separate unstable packages > > The other thing we need to worry about is getting dependencies right across > the packages since the Virtuoso and FullText libraries rely on the core > library. > > Rob > > From: Kal Ahmed <ka...@ne...> > Reply-To: dotNetRDF Developer Discussion and Feature Request > <dot...@li...> > Date: Tuesday, April 16, 2013 12:58 AM > To: dotNetRDF Developer Discussion and Feature Request > <dot...@li...> > Subject: Re: [dotNetRDF-Develop] NuGet Packaging > > Hi, > > One problem with NuGet versioning is that they have chopped off the build > number, which means that if we have separate unstable packages we > potentially have issues in keeping the unstable package version and the > stable package version properly aligned. > > It looks like NuGets pre-release versioning uses the last string part of the > package version to order packages from oldest to newest. So if we went for > publishing pre-release versions we could use a scheme like > {maj}.{min}.{patch}-nightly{YYMMDD} e.g. 1.0.1-nightly130416. This way all > nightly builds for a given release level stay in the correct order with the > 1.0.1 release build being considered newer than all 1.0.1-nightlyXXXXXX > builds. > > For those reasons, I think that to start with using NuGet pre-release > versioning makes sense - it still leaves us the option of introducing > "unstable" packages later. > > Cheers > > Kal > > > On Mon, Apr 15, 2013 at 10:07 PM, Rob Vesse <rv...@do...> wrote: >> >> Hey All >> >> This email is part information sharing on how I currently package and >> upload dotNetRDF for NuGet but also to start a discussion on the possibility >> of making unstable builds available via NuGet which would make it easier for >> users to consume and verify bug fixes. >> >> Packaging >> >> Currently packaging is done via pre-build NuSpec files and NAnt targets. >> Under Build/nuget/ in the repo you will find a sub-directory for each >> package we produce. In a clean repo this will contain only a .nuspec file >> and possibly a readme.txt if the package requires one. >> >> To generate the NuGet packages use NAnt and one of the following targets: >> >> dist-libs-nuget – Builds all the NuGet packages >> dist-libs-nuget-core – Build the core library package >> dist-libs-nuget-data-virtuoso – Build the Data.Virtuoso package >> dist-libs-nuget-query-fulltext – Builds the Query.FullText package >> >> These targets rely on various other targets so will compile things as >> necessary. >> >> Uploading >> >> Uploading the releases is done via NAnt, the equivalent NAnt targets for >> the aforementioned targets simply replace dist with upload in the target >> name. >> >> Publishing Nightly Builds >> >> Tom has suggested that as part of getting our CI infrastructure properly >> spun up we should push out nightly builds to NuGet automatically. Currently >> the only means we have for distributing nighties is via the binaries-nightly >> repo we maintain at SourceForge which relies on a developer manually >> uploading a new build. >> >> The main barrier to this with NuGet as I understand it is that unlike >> Java/Maven where you can specify SNAPSHOT on the end of your version and >> have the server generate unique version numbers for you with NuGet you have >> to specify a unique version number each time. So we need some mechanism to >> inject version numbers into the nuspec files, NuGet does appear to support >> placeholders but we would need to test to make sure these work as described. >> We would also need to make sure that if we take this approach that we are >> using * in the build field of our AssemblyVersion attributes so that we get >> an incrementing version number. >> >> The other issue is where to publish these, we can either publish to a >> separate package ID which is explicitly described as Nightly/Unstable or we >> can publish unstable releases directly to the main feeds using the NuGet >> pre-release functionality >> (http://docs.nuget.org/docs/reference/versioning#Prerelease_Versions) >> >> There are arguments for both approaches: >> >> Separate package separates more cleanly from stable releases BUT >> introduces noise into NuGet search results unless we only publish >> pre-release builds to the unstable channel (pre-release builds are hidden by >> default from search results) >> Separate package allows us to have a package with more owners so any >> developer can publish to it, same package means expanding owner list >> Publishing pre-release versions avoids having to have separate packages >> for every package we have (currently 3) >> Publishing pre-release versions makes it easier for NuGet users to switch >> their dependency to the nightly build without changing their package >> dependencies. >> >> Thoughts and suggestions in this area are welcome, >> >> Rob >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> > > > > -- > Kal Ahmed > Director, Networked Planet Limited > e: kal...@ne... > w: www.networkedplanet.com > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced analytics > on semi-structured data. The platform includes APIs for building apps and a > phenomenal toolset for data science. Developers can use our toolset for easy > data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________ > dotNetRDF-develop mailing list dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > |
From: Tomasz P. <tom...@gm...> - 2013-04-18 20:46:26
|
Hi again I have been struggling to put those file somewhere on the system and fool msbuild to use them but it didn't seem to work. I settled for a compromise, which is keeping the files in a separate repo [1], which is fetched on top of the main files and the Phone csproj is patched as needed. Now all builds fine and we won't need to pollute the solution. Tom [1]: https://bitbucket.org/dotnetrdf/wp7hack On Wed, Apr 17, 2013 at 10:36 AM, Khalil Ahmed <ka...@ne...> wrote: > Its probably Hyper-V that is causing the failure. If you are installing on > to a machine that doesn't meet the requirements for Hyper-V then the > emulator won't install. I think you are probably stuck with having to put > the files somewhere - either in the repo or in some location external to the > repo that is then configured in the build process. > > K > > > On Wed, Apr 17, 2013 at 7:27 AM, Tomasz Pluskiewicz > <tom...@gm...> wrote: >> >> Rob >> >> I did try that. Still, it fails on installing Windows Phone Emulator >> x64. The error is something with VMM service, which I don't have and >> couldn't find a way to install. >> >> However on second thought if I was able to put the WP7 files in repo I >> should be able to copy them where they belong without installing and I >> hope it will work too. >> >> Tom >> >> On Wed, Apr 17, 2013 at 12:24 AM, Rob Vesse <rv...@do...> wrote: >> > Tom >> > >> > You can install WP7 tools on Windows Server 2008 because I used to build >> > releases on my Server 2008 machine when I was at the University of >> > Southampton >> > >> > See http://blogs.msdn.com/b/astebner/archive/2010/05/02/10005980.aspx >> > which details the steps necessary, basically you have to extract the >> > installer and modify a config file >> > >> > Rob >> > >> > On 4/16/13 1:30 PM, "Tomasz Pluskiewicz" <tom...@gm...> >> > wrote: >> > >> >>Hi Rob, Kal >> >> >> >>I have been able to force TeamCity to build dotNetRDF with relatively >> >>minimal changes. Please refer to my fork [1]. I have switched from >> >>MSTest to NUnit and done some minor changes to csproj files. There is >> >>also a proposal to change the integration tests to come out >> >>inconclusive instead of failed when test config is missing... >> >> >> >>Most noteworthy is the latest commit in the 'WP7 Hack' branch. >> >>Unfortunately I found out the hard way that Windows Phone SDK 7.1 is >> >>not only unsuppported on Windows Server 2008 R2, it is completely >> >>uninstallable! The only working solution I found was to stuff 14 MB of >> >>WP7 SDK files and build targets and have the WindowsPhone project use >> >>them instead of the defaults. This way the whole solution builds fine >> >>from sln file using msbuild. >> >> >> >>You can have a look at the project here: http://ci.t-code.pl (guest >> >>login enabled) >> >> >> >>Regarding your eariler emails, I think that version numbering should >> >>be moved from solution to TeamCity completely. This way we can >> >>flexibly control that number and pass it between build >> >>steps/configurations. >> >> >> >>Next step will be to build and publish nuget packages. Satisfying >> >>dependencies between packages will have to be done in some kind of >> >>nuspec patching step to modify the <dependency> tags. Hence why we >> >>need to control the version withing the CI server. >> >> >> >>I will write more when the TC configuration is more complete >> >> >> >>Tom >> >> >> >>[1]: https://bitbucket.org/tpluscode/dotnetrdf-teamcity >> >> >> >> >> >>-------------------------------------------------------------------------- >> >>---- >> >>Precog is a next-generation analytics platform capable of advanced >> >>analytics on semi-structured data. The platform includes APIs for >> >> building >> >>apps and a phenomenal toolset for data science. Developers can use >> >>our toolset for easy data analysis & visualization. Get a free account! >> >>http://www2.precog.com/precogplatform/slashdotnewsletter >> >>_______________________________________________ >> >>dotNetRDF-develop mailing list >> >>dot...@li... >> >>https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> > >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Precog is a next-generation analytics platform capable of advanced >> > analytics on semi-structured data. The platform includes APIs for >> > building >> > apps and a phenomenal toolset for data science. Developers can use >> > our toolset for easy data analysis & visualization. Get a free account! >> > http://www2.precog.com/precogplatform/slashdotnewsletter >> > _______________________________________________ >> > dotNetRDF-develop mailing list >> > dot...@li... >> > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> dotNetRDF-develop mailing list >> dot...@li... >> https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > > > > > -- > Kal Ahmed > Director, Networked Planet Limited > e: kal...@ne... > w: www.networkedplanet.com > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > dotNetRDF-develop mailing list > dot...@li... > https://lists.sourceforge.net/lists/listinfo/dotnetrdf-develop > |
From: <tr...@do...> - 2013-04-18 00:12:21
|
<p>A new comment has been added to the following issue.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Upgrade support for Turtle 1.1 and TriG to latest drafts</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Rob Vesse</td> </tr> <tr> <td><b>Date:</b></td> <td>2013-04-18 01:11 AM</td> </tr> <tr> <td><b>Comment:</b></td> </tr> <tr> <td colspan="2"><ul> <li> Turtle 1.1 is now a W3C Candidate Recommendation - <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a></li> <li> TriG is a First Public Working Draft - <a href="http://www.w3.org/TR/trig/">http://www.w3.org/TR/trig/</a></li> </ul></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=314" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=314</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-17 22:47:39
|
<p>The following issue has been updated by Rob Vesse:</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support a ReadWrite variant of SparqlConnector that uses SPARQL Update for write operations</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td colspan="2"><b>Changes:</b></td> </tr> <tr> <td colspan="2"> <ul> <li>Assigned to changed from "Unassigned" to "none" </li> <li>Progress changed from "50 %" to "85 %" </li> </ul> </td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-17 22:47:21
|
<p>A new comment has been added to the following issue.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support a ReadWrite variant of SparqlConnector that uses SPARQL Update for write operations</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Rob Vesse</td> </tr> <tr> <td><b>Date:</b></td> <td>2013-04-17 11:46 PM</td> </tr> <tr> <td><b>Comment:</b></td> </tr> <tr> <td colspan="2"><p> I now have most of the unit tests in place and passing. I will not integrate this into 1.0.0 because it is new and relatively untested and I still have some additional unit tests I wish to add.</p></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <dot...@li...> - 2013-04-17 22:41:11
|
Send dotNetRDF-commits mailing list submissions to dot...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits or, via email, send a message with subject or body 'help' to dot...@li... You can reach the person managing the list at dot...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of dotNetRDF-commits digest..." Today's Topics: 1. commit/dotnetrdf: 2 new changesets (Bitbucket) 2. commit/dotnetrdf: tpluscode: Removed the compiler conditionals for HTTP debugging (Bitbucket) 3. commit/dotnetrdf: 3 new changesets (Bitbucket) 4. commit/dotnetrdf: rvesse: Add missing XML comments (Bitbucket) 5. commit/dotnetrdf: 5 new changesets (Bitbucket) 6. commit/dotnetrdf: 6 new changesets (Bitbucket) 7. commit/dotnetrdf: 2 new changesets (Bitbucket) 8. commit/dotnetrdf: 6 new changesets (Bitbucket) 9. commit/dotnetrdf: 2 new changesets (Bitbucket) ---------------------------------------------------------------------- Message: 1 Date: Fri, 12 Apr 2013 23:36:32 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/6dcf8697ffa2/ Changeset: 6dcf8697ffa2 User: rvesse Date: 2013-04-13 01:22:29 Summary: Add missing license header Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a5677b33bd05/ Changeset: a5677b33bd05 User: rvesse Date: 2013-04-13 01:36:19 Summary: Fixes for Silverlight and Windows Phone 7 builds Affected #: 9 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 2 Date: Mon, 15 Apr 2013 21:14:16 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: tpluscode: Removed the compiler conditionals for HTTP debugging To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a91b5aa9ec6a/ Changeset: a91b5aa9ec6a Branch: CORE-347 User: tpluscode Date: 2013-04-15 23:11:47 Summary: Removed the compiler conditionals for HTTP debugging Affected #: 29 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 3 Date: Mon, 15 Apr 2013 21:44:20 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 3 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 3 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b01870b641e5/ Changeset: b01870b641e5 Branch: CORE-347 User: rvesse Date: 2013-04-15 23:43:04 Summary: Keep relevant Tools methods for HTTP Debugging public as they may be useful to users who role their own HTTP code in conjunction with dotNetRDF (CORE-347) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/852aeac1d292/ Changeset: 852aeac1d292 Branch: CORE-347 User: rvesse Date: 2013-04-15 23:43:32 Summary: Close the CORE-347 branch Affected #: 0 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/342e023aed48/ Changeset: 342e023aed48 User: rvesse Date: 2013-04-15 23:44:06 Summary: Merge removal of DEBUG conditional compilation for HTTP debugging features from CORE-347 branch Affected #: 29 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 4 Date: Mon, 15 Apr 2013 23:05:38 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: rvesse: Add missing XML comments To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 1 new commit in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b351e17fd8da/ Changeset: b351e17fd8da User: rvesse Date: 2013-04-16 01:05:27 Summary: Add missing XML comments Affected #: 6 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 5 Date: Wed, 17 Apr 2013 00:20:53 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 5 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 5 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/0fc87cf41a34/ Changeset: 0fc87cf41a34 User: rvesse Date: 2013-04-17 00:49:07 Summary: Fix a couple of tests that contained a bad resource path Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/029170451dd4/ Changeset: 029170451dd4 User: rvesse Date: 2013-04-17 00:53:40 Summary: Fix a test affected by fix to GROUP_CONCAT, fix another test that wasn't correctly isolated Affected #: 3 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/7b5b01a54a5d/ Changeset: 7b5b01a54a5d User: rvesse Date: 2013-04-17 01:03:20 Summary: Fix a regression in Fuseki support around DESCRIBE queries Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/4842ee974e49/ Changeset: 4842ee974e49 User: rvesse Date: 2013-04-17 01:50:40 Summary: Fix a couple of tests that were relying on the recently fixed behaviour around QName resolution (CORE-341) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/14a590546933/ Changeset: 14a590546933 User: rvesse Date: 2013-04-17 02:07:11 Summary: Update ReadMe, Release Notes and Change Log in preparation for upcoming release Affected #: 4 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 6 Date: Wed, 17 Apr 2013 20:18:23 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 6 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 6 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a0fc9a08c800/ Changeset: a0fc9a08c800 User: rvesse Date: 2013-04-17 22:01:33 Summary: Add additional test for purported memory leak, may be illustrating a slight leak but still unclear Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/7f976fa99ada/ Changeset: 7f976fa99ada User: rvesse Date: 2013-04-17 22:06:27 Summary: Slight test tweak Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/c41283638cf3/ Changeset: c41283638cf3 Branch: json-net-5 User: rvesse Date: 2013-04-17 22:09:45 Summary: Bump Json.Net version to 5.0.3 Affected #: 18 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/05d04486ee06/ Changeset: 05d04486ee06 Branch: json-net-5 User: rvesse Date: 2013-04-17 22:16:51 Summary: Validated that Json.Net upgrade did not cause any regressions in relevant tests and solution still builds, note upgrade in ChangeLog Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/b7235e3dd0ce/ Changeset: b7235e3dd0ce Branch: json-net-5 User: rvesse Date: 2013-04-17 22:17:11 Summary: Close the Json.Net 5.0.3 upgrade branch Affected #: 0 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/1967288c0599/ Changeset: 1967288c0599 User: rvesse Date: 2013-04-17 22:17:37 Summary: Merge in upgrade to Json.Net 5.0.3 Affected #: 19 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 7 Date: Wed, 17 Apr 2013 20:29:30 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/9782816258fb/ Changeset: 9782816258fb User: rvesse Date: 2013-04-17 22:28:42 Summary: Further test tweaks Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/e58afe038352/ Changeset: e58afe038352 User: rvesse Date: 2013-04-17 22:29:19 Summary: Further test tweaks Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 8 Date: Wed, 17 Apr 2013 22:23:14 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 6 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 6 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/0e49f8f442d2/ Changeset: 0e49f8f442d2 Branch: CORE-346 User: rvesse Date: 2013-04-17 23:26:20 Summary: Start stubbing out ReadWriteSparqlConnector, make necessary methods of SparqlConnector virtual (CORE-346) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/927256db3153/ Changeset: 927256db3153 Branch: CORE-346 User: rvesse Date: 2013-04-17 23:40:14 Summary: More stub work for ReadWriteSparqlConnector (CORE-346) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/8ec253230d88/ Changeset: 8ec253230d88 Branch: CORE-346 User: rvesse Date: 2013-04-17 23:47:57 Summary: Define additional classes and properties for Configuration vocabulary needed to serialize a ReadWriteSparqlConnector successfully (CORE-346) Affected #: 2 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/ae60ce651e84/ Changeset: ae60ce651e84 Branch: CORE-346 User: rvesse Date: 2013-04-17 23:57:00 Summary: Rejig config serialization for SPARQL endpoints to use more specific properties (CORE-346) Affected #: 4 files https://bitbucket.org/dotnetrdf/dotnetrdf/commits/5481af984898/ Changeset: 5481af984898 Branch: CORE-346 User: rvesse Date: 2013-04-18 00:05:34 Summary: Fix up the ReadWriteSparqlConnector code some more (CORE-346) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/a78e49038f44/ Changeset: a78e49038f44 Branch: CORE-346 User: rvesse Date: 2013-04-18 00:22:00 Summary: Implement Update(), UpdateGraph() and DeleteGraph() for ReadWriteSparqlConnector (CORE-346) Affected #: 1 file Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ Message: 9 Date: Wed, 17 Apr 2013 22:41:03 -0000 From: Bitbucket <com...@bi...> Subject: [dotNetRDF Commits] commit/dotnetrdf: 2 new changesets To: dot...@li... Message-ID: <201...@bi...> Content-Type: text/plain; charset="utf-8" 2 new commits in dotnetrdf: https://bitbucket.org/dotnetrdf/dotnetrdf/commits/471153a24000/ Changeset: 471153a24000 Branch: CORE-346 User: rvesse Date: 2013-04-18 00:26:18 Summary: Implement SaveGraph() for ReadWriteSparqlConnector (CORE-346) Affected #: 1 file https://bitbucket.org/dotnetrdf/dotnetrdf/commits/de0ea746f93a/ Changeset: de0ea746f93a Branch: CORE-346 User: rvesse Date: 2013-04-18 00:40:47 Summary: Unit tests and bug fixes for ReadWriteSparqlConnector (CORE-346) Affected #: 3 files Repository URL: https://bitbucket.org/dotnetrdf/dotnetrdf/ -- This is a commit notification from bitbucket.org. You are receiving this because you have the service enabled, addressing the recipient of this email. ------------------------------ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ------------------------------ _______________________________________________ dotNetRDF-commits mailing list dot...@li... https://lists.sourceforge.net/lists/listinfo/dotnetrdf-commits End of dotNetRDF-commits Digest, Vol 7, Issue 3 *********************************************** |
From: <tr...@do...> - 2013-04-17 22:23:42
|
<p>The following issue has been updated by Rob Vesse:</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support a ReadWrite variant of SparqlConnector that uses SPARQL Update for write operations</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td colspan="2"><b>Changes:</b></td> </tr> <tr> <td colspan="2"> <ul> <li>Assigned to changed from "Unassigned" to "none" </li> <li>Progress changed from "0 %" to "50 %" </li> </ul> </td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-17 22:23:35
|
<p>A new comment has been added to the following issue.</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support a ReadWrite variant of SparqlConnector that uses SPARQL Update for write operations</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td><b>Created By:</b></td> <td>Rob Vesse</td> </tr> <tr> <td><b>Date:</b></td> <td>2013-04-17 11:22 PM</td> </tr> <tr> <td><b>Comment:</b></td> </tr> <tr> <td colspan="2"><p> Have some of this implemented but not yet tested, needed to finish implementation and create relevant unit tests</p></td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-17 21:22:09
|
<p>The following issue has been updated by Rob Vesse:</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Support a ReadWrite variant of SparqlConnector that uses SPARQL Update for write operations</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td colspan="2"><b>Changes:</b></td> </tr> <tr> <td colspan="2"> <ul> <li>Status changed from "Planned" to "In Progress" </li> <li>Assigned to changed from "Unassigned" to "none" </li> </ul> </td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=346</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |
From: <tr...@do...> - 2013-04-17 21:20:19
|
<p>The following issue has been updated by Rob Vesse:</p> <table border="0"> <tr> <td width="90px" valign="top"><b>Title:</b></td> <td>Refactor Conditional Compilation to throw PlatformNotSupportedException rather than eliminating methods</td> </tr> <tr> <td><b>Project:</b></td> <td>Core Library (dotNetRDF.dll)</td> </tr> <tr> <td colspan="2"><b>Changes:</b></td> </tr> <tr> <td colspan="2"> <ul> <li>Priority changed from "High" to "Low" </li> <li>Milestone changed from "1.0.1" to "Unscheduled" </li> </ul> </td> </tr> </table> <p> More information on this issue can be found at <a href="http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=331" target="_blank">http://www.dotnetrdf.org/tracker/Issues/IssueDetail.aspx?id=331</a></p> <p style="text-align:center;font-size:8pt;padding:5px;"> If you no longer wish to receive notifications, please visit <a href="http://www.dotnetrdf.org/tracker/Account/UserProfile.aspx" target="_blank">your profile</a> and change your notifications options. </p> |