Re: [Monotone-devel] Release time
Am 27.05.2010 18:54, schrieb Jack Lloyd: On Thu, May 27, 2010 at 09:38:32AM +0200, Thomas Keller wrote: Apropos release - a fellow developer reminded me that we *might* want to set a proper release number for the next release (you know what I'm talking about, 1.0...) - given the fact that we're still recognized as alpha software in a couple of places. What do you think? Just for the sake of argument: While 1.0 is good for a public image perspective, is it something that you want to lock yourself into? I can think of a few things that might potentially happen that might be harder to pull off post-1.0: - s/netxx/asio/ - netsync over TLS - policy branches (or some equivalent change; mtn's inability to do proper per-branch security is actually a big problem for me - it makes me nervous giving out write access to public projects, because while I'd be fine giving some random person write access to some particular subbranch that I could pull changes from, I wouldn't want them to be able to scribble elsewhere, even by accident. Limitations in this area also make me nervous about putting branches that have to remain private/secure on my public mtn server). Other people already responded here, just my 2 ct: I've just recently stumbled across your TLS feature request in the tracker from 2006 and simply put, if there was just not enough man power to do that until now, I don't think it will happen until 1.0 either (if 1.0 should be out this year or beginning of next year). The same is true for policy branches (which recently saw more development though, thanks to Tim) and the replacement of netxx (what we should not only do for cosmetic reasons, but also for better IPv6 support). My main point is: We need more users! More users means more development (directly because of feedback and eventually indirectly because of more submitted patches). And I fear that if we only ever think in small steps and improvements like in the years before, this project will probably die off in the future silently because it won't get noticed and fewer and fewer new people will hack on it. This is why I started to blog more about monotone in my personal blog and why I syndicated it on monotone's home page. To generate more more interest, more buzz, more traffic. After all we should all agree that monotone has been proven stable for many, many versions now and that we (the original and today's developers) should be proud of it, so proud that we should dare to put a proper version label on this darn thing. Jack, don't get me wrong, all the above mentioned features are surely important (and I'd love to see them implemented), but I don't think they should block 1.0 any longer. BTW, a minor suggestion: if the next release is 1.0, perhaps this would be the time to switch the versioning scheme? 1.0 implies stability, so people will be surprised if there are major changes between, say, 1.23 and 1.24. Going to a triplet major.minor.patch ala Linux kernel would make it easier for users to see which were small or bugfix releases (1.0.4-1.0.5) and which were larger (1.0.5-1.1.0). (OTOH one could represent larger changes by going to 2.x, 3.x, ... as well, so I suppose this is a bit of bikeshedding) I agree that continueing the current versioning scheme, just with a prefixed 1., won't make much sense any longer, but I'm against complicating this too much. A new easy rule for now could be: 1) if a release only consists of bug fixes or has small, not BC-breaking improvements (esp. in respect to automate), raise the patch release 2) if a release has bigger improvements or breaks BC, raise the minor version 3) if a major flag day introduces major new things or we've rewritten 90% of monotone (:)), raise the major number. 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] Release time
I couldn't agree more with Thomas's point about Monotone dying if we are not careful. It's a psychological thing. `Oh it's only at 0.xxx - still unstable'. We have all done that at some point when looking at rival projects as an end user in a hurry to get something up and running. It's only if something catches our eye that we change our mind - with mtn it was the documentation. When choosing a new SCM system our SDA recommended Monotone but asked a few of us to look into the subject. Like most people I was unhappy about trusting something at version 0.34 with storing our 11 year old CVS based project. But I trialled out both mtn and git. Apart from agreeing that mtn was definitely the way to go (much cleaner design, everything worked as documented, good clear documentation and interface etc), the only thing that puzzled me was the version. It was more like 3.4 and not 0.34. We now have a db ~ 1.5GB, 20k revisions, about ~1K branches and ~8K tags and going strong. When giving monotone presentations and demos the most common question is about it being beta software at version 0.xx... To not go to 1.x in the very near future will be monotone's death sentence, it's probably already too late thanks to GIT. I really hope I'm wrong about this as I want the better product to win... Am 27.05.2010 18:54, schrieb Jack Lloyd: On Thu, May 27, 2010 at 09:38:32AM +0200, Thomas Keller wrote: Apropos release - a fellow developer reminded me that we *might* want to set a proper release number for the next release (you know what I'm talking about, 1.0...) - given the fact that we're still recognized as alpha software in a couple of places. What do you think? Just for the sake of argument: While 1.0 is good for a public image perspective, is it something that you want to lock yourself into? I can think of a few things that might potentially happen that might be harder to pull off post-1.0: - s/netxx/asio/ - netsync over TLS - policy branches (or some equivalent change; mtn's inability to do proper per-branch security is actually a big problem for me - it makes me nervous giving out write access to public projects, because while I'd be fine giving some random person write access to some particular subbranch that I could pull changes from, I wouldn't want them to be able to scribble elsewhere, even by accident. Limitations in this area also make me nervous about putting branches that have to remain private/secure on my public mtn server). Other people already responded here, just my 2 ct: I've just recently stumbled across your TLS feature request in the tracker from 2006 and simply put, if there was just not enough man power to do that until now, I don't think it will happen until 1.0 either (if 1.0 should be out this year or beginning of next year). The same is true for policy branches (which recently saw more development though, thanks to Tim) and the replacement of netxx (what we should not only do for cosmetic reasons, but also for better IPv6 support). My main point is: We need more users! More users means more development (directly because of feedback and eventually indirectly because of more submitted patches). And I fear that if we only ever think in small steps and improvements like in the years before, this project will probably die off in the future silently because it won't get noticed and fewer and fewer new people will hack on it. This is why I started to blog more about monotone in my personal blog and why I syndicated it on monotone's home page. To generate more more interest, more buzz, more traffic. After all we should all agree that monotone has been proven stable for many, many versions now and that we (the original and today's developers) should be proud of it, so proud that we should dare to put a proper version label on this darn thing. Jack, don't get me wrong, all the above mentioned features are surely important (and I'd love to see them implemented), but I don't think they should block 1.0 any longer. BTW, a minor suggestion: if the next release is 1.0, perhaps this would be the time to switch the versioning scheme? 1.0 implies stability, so people will be surprised if there are major changes between, say, 1.23 and 1.24. Going to a triplet major.minor.patch ala Linux kernel would make it easier for users to see which were small or bugfix releases (1.0.4-1.0.5) and which were larger (1.0.5-1.1.0). (OTOH one could represent larger changes by going to 2.x, 3.x, ... as well, so I suppose this is a bit of bikeshedding) I agree that continueing the current versioning scheme, just with a prefixed 1., won't make much sense any longer, but I'm against complicating this too much. A new easy rule for now could be: 1) if a release only consists of bug fixes or has small, not BC-breaking improvements (esp. in respect to automate), raise the patch release 2) if a release has bigger improvements or breaks BC, raise
Re: [Monotone-devel] Release time - au stdio update
CooSoft Support supp...@coosoft.plus.com writes: I looked at the release notes and documentation regarding au stdio changes and read up on the new update command. Virtually all other au commands if not all simply mention what comes out on stdout by implication (apart from the barfing to stderr and exiting on error bit), update specifically mentioned stderr with reference to progress output, hence my, unfounded, concern. Ok. But this does suggest that the manual could be improved; it should say those messages are in the p channel with stdio. I'll fix that. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
On 28.05.2010 10:23, CooSoft Support wrote: I couldn't agree more with Thomas's point about Monotone dying if we are not careful. It's a psychological thing. `Oh it's only at 0.xxx - still unstable'. Sure it's psychological and nowadays in the age of OSS, versioning schemes or rather the progress of their numbers are often not really expressive. Wine took 10 years to release 1.0 and noone really cared in the end, because it has been working for ages before. On the other hand I've seen software for example in a 5.x version and was hugely wondering what that thing did the four major versions before. People shouldn't look at the numbers of the version but rather on the feature list on the project's website. Maybe somewhere on that website there should be included a sentence like We use it all the time and no problems so far. Like Jack, I personally use Monotone for all my work stuff, source codes, server configs, etc. My lady is using Monotone for her thesis. No problems ever, so count that as +2 from here :-) One problem of a 1.0 or 1.0.0 release could be, that the more sophisticated users from bigger development groups, which then start to use monotone because of the major release, often stick to a version they chose in the beginning of a project. Of course they still want to have bugfix releases, but by no means they want breakage in the API or interface or whatever applies. I've seen this happen on another project I accompanied a while ago. As soon as they put out 1.0 there only came bugfix releases afterwards, although many requests for mostly the same improvements appeared on the mailing list and the excuse always was like No we don't do that, because then we would break with the big guys. Does Monotone have the power to support two branches, so that new and needed features don't get stalled? Just a few thoughts :-) Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
Thomas Keller m...@thomaskeller.biz writes: After all we should all agree that monotone has been proven stable for many, many versions now and that we (the original and today's developers) should be proud of it, so proud that we should dare to put a proper version label on this darn thing. +2 :). BTW, a minor suggestion: if the next release is 1.0, perhaps this would be the time to switch the versioning scheme? 1.0 implies stability, so people will be surprised if there are major changes between, say, 1.23 and 1.24. Going to a triplet major.minor.patch ala Linux kernel would make it easier for users to see which were small or bugfix releases (1.0.4-1.0.5) and which were larger (1.0.5-1.1.0). (OTOH one could represent larger changes by going to 2.x, 3.x, ... as well, so I suppose this is a bit of bikeshedding) I agree that continueing the current versioning scheme, just with a prefixed 1., won't make much sense any longer, but I'm against complicating this too much. A new easy rule for now could be: 1) if a release only consists of bug fixes or has small, not BC-breaking improvements (esp. in respect to automate), raise the patch release 2) if a release has bigger improvements or breaks BC, raise the minor version 3) if a major flag day introduces major new things or we've rewritten 90% of monotone (:)), raise the major number. +1 -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
Am 28.05.2010 15:07, schrieb Philipp Gröschler: On 28.05.2010 10:23, CooSoft Support wrote: I couldn't agree more with Thomas's point about Monotone dying if we are not careful. It's a psychological thing. `Oh it's only at 0.xxx - still unstable'. Sure it's psychological and nowadays in the age of OSS, versioning schemes or rather the progress of their numbers are often not really expressive. Wine took 10 years to release 1.0 and noone really cared in the end, because it has been working for ages before. On the other hand I've seen software for example in a 5.x version and was hugely wondering what that thing did the four major versions before. Absolutely right, I don't want to increase the major version every few months from now on either, but I also don't think we should follow Wine's example here. Six years are enough :) People shouldn't look at the numbers of the version but rather on the feature list on the project's website. Maybe somewhere on that website there should be included a sentence like We use it all the time and no problems so far. Like Jack, I personally use Monotone for all my work stuff, source codes, server configs, etc. My lady is using Monotone for her thesis. No problems ever, so count that as +2 from here :-) Tony mentioned some praise as well, and hey, we even have a dedicated wiki page to add this: http://monotone.ca/wiki/Testimonials/ So don't be shy and add your comments there - I'll happily link this wiki page on the front page! One problem of a 1.0 or 1.0.0 release could be, that the more sophisticated users from bigger development groups, which then start to use monotone because of the major release, often stick to a version they chose in the beginning of a project. Of course they still want to have bugfix releases, but by no means they want breakage in the API or interface or whatever applies. I've seen this happen on another project I accompanied a while ago. As soon as they put out 1.0 there only came bugfix releases afterwards, although many requests for mostly the same improvements appeared on the mailing list and the excuse always was like No we don't do that, because then we would break with the big guys. Does Monotone have the power to support two branches, so that new and needed features don't get stalled? For that to happen we'd need to have more of these big guys in first instance - and I'd love to support them all. From a management point of view I don't care if I handle one single branch or two, a stable and a feature branch, or whatever works for them. 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] Release time
On Fri, May 28, 2010 at 1:30 AM, Thomas Keller m...@thomaskeller.biz wrote: I agree that continueing the current versioning scheme, just with a prefixed 1., won't make much sense any longer, but I'm against complicating this too much. A new easy rule for now could be: 1) if a release only consists of bug fixes or has small, not BC-breaking improvements (esp. in respect to automate), raise the patch release 2) if a release has bigger improvements or breaks BC, raise the minor version 3) if a major flag day introduces major new things or we've rewritten 90% of monotone (:)), raise the major number. I think that pretty much agrees with http://apr.apache.org/versioning.htmlwhich is referenced by various other projects. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
Derek Scherger spake unto us the following wisdom: 1) if a release only consists of bug fixes or has small, not BC-breaking improvements (esp. in respect to automate), raise the patch release 2) if a release has bigger improvements or breaks BC, raise the minor version 3) if a major flag day introduces major new things or we've rewritten 90% of monotone (:)), raise the major number. I think that pretty much agrees with http://apr.apache.org/versioning.htmlwhich is referenced by various other projects. I'd modify this somewhat, for monotone, because *network* compatability is quite possibly its most visible feature. Perhaps something like: Major version bump - netsync incompatability (or major features you don't want people to miss) Minor version bump - database upgrade required (or ...) patchlevel - bug fixes, minor changes, user can upgrade without concern toward databases or interoperability This is along the lines of typical library versioning, with minor versions indicating link-compatible changes, and major versions requiring relinking. (The binary compatability prose in the Apache page above.) That said, versioning is *way* bikeshed. Everyone has their own opinion on how it should be handled. I think the important thing here is to pick *something* meaningful and stick to that meaning. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #29982] Windows installer does not install documentation CSS and images
Update of bug #29982 (project monotone): Assigned to:None = zzagorski Open/Closed:Open = Accepted ___ Reply to this item at: http://savannah.nongnu.org/bugs/?29982 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
