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
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
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
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
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.
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
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
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
Update of bug #29982 (project monotone):
Assigned to:None = zzagorski
Open/Closed:Open = Accepted
___
Reply to this item at:
