Re: [Monotone-devel] Time for a release
Thomas Keller schrieb: > Its been a while already since 0.41 and I'd like to prepare a new > release - probably the last one for 2008 ;) > [...] > * I've noticed a couple of fixes and changes on IRC which haven't made > it into the NEWS file yet. Would the developers who're now thinking they > could be meant please be so kind and add them? :) I've updated the NEWS file with anything which I found noteworthy since 0.41. Please re-read and correct possible spelling / grammar / context errors, in particular the sections about the improvements / bugfixes from Timothy (since I may not have grasp the real indications / outcome here). Thanks, Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] interface versions, again
Hi all! This topic nags me from time to time and it has bitten me again during my preparations for 0.42: Proper interface version numbering. So for this release I've seen all kinds of wrong interface numbers - in code and in documentation - which ranged from 7.1 to 8.2. 7.1 is obviously wrong since 0.41 already shipped with 8.0 and this was probably just a leftover from an earlier change in a branch. Problematic is, however, to decide if a version number has to be raised or not and moreover, if it has already been raised _after_ the last release. Things like "rolling over" version numbers suddenly become important, i.e. if change X requires a major bump from 8.0 to 9.0, its no longer required to add a minor bump from 9.0 to 9.1 for a new feature. So, to make a long story short I propose that interface versions are _not_ changed by individual developers up until the next release and that the release manager rather takes care of the numbering, just because he gets the ultimative overview what has been added / changed when he writes the NEWS file. As a little reminder (which I may fill into the release checklist some time) the interface number has to be added / changed in at least these places: * cmd_automate.cc (static string 'interface_version') * monotone.texi (where various commands may reference it in "added in" or "changes" sections) * the monotone wiki under http://monotone.ca/wiki/AutomateVersions/, alongside with new / updated / changed commands for the particular version Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] sutures [Re: Time for a release]
Hello, On Sun, Dec 14, 2008 at 09:22:10AM -0500, Stephen Leake wrote: > > A few things have to happen before, though: > > > > * Had anybody beside the implementor taken a deeper look and tried the > > new mtn conflicts functionality? Is this ready to ship as is? > > not to my knowledge; one person used it and aggreed it was an > improvement over the current conflict resolution process (which is > still there). What is the status of the planned "file sutures"? Are they related to the new conflicts functionality? I am asking mainly because they could fix a really annoying problem with "pluck" IIUC: that if you pluck a revision which introduces a file, monotone does not recognize it as the same file as the original one and subsequent pluck which modify this file will fail. See http://lists.gnu.org/archive/html/monotone-devel/2007-08/msg00159.html Pavel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Matthew Nicholson schrieb: >> What I'd like to see even more than another list of wanted features are >> a couple of people who put their names here on the list or on this wiki >> page saying "yes, I want to _work_ on this topic and I think I _can_ >> do it!" >> If this does not happen, I'm afraid this gets another wishlist which >> won't be implemented anytime soon. >> > > Great idea. I also think we need some kind of guide to monotone > development (which we may already have). This guide would contain > descriptions of the macros we use and the principles that monotone is > developed by. Nah, I really spoke about the aforementioned wiki page. You're describing our HACKING file which is already present ;) However, it might be nice to put this into the wiki so it can be formatted nicely and is easier accessible. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Monotone Mini Summit: 2009-01-18 - 2009-01-19
Thomas Keller wrote: Hi Matthew! At first thanks for taking the initiative to organize the Mini Summit! You wrote: I have started a wiki page[1] with these ideas. Feel free to edit that page, and please also continue to discuss ideas on the mailing list. I would like to have a solid list of things to work on by January 12th, and then flesh those out for a week until the 17th so that we have a solid agenda for our virtual summit. [1] http://mtn-wiki.1erlei.de/wiki/MtnSummit/2009 What I'd like to see even more than another list of wanted features are a couple of people who put their names here on the list or on this wiki page saying "yes, I want to _work_ on this topic and I think I _can_ do it!" If this does not happen, I'm afraid this gets another wishlist which won't be implemented anytime soon. Great idea. I also think we need some kind of guide to monotone development (which we may already have). This guide would contain descriptions of the macros we use and the principles that monotone is developed by. -- Matthew Nicholson matt-land.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel