From: Sean E. <sea...@gm...> - 2004-08-28 17:19:23
|
0.82.1 officially broke our versioning system. In case you didn't know, our versioning system was entirely sequential. 0.82 was the 82nd release of Gaim ever. Even though 0.82.1 isn't much of a "release" on its own, it defies the versioning system. What to do? We could go on, and pretend nothing ever happened. Make the next release 0.83, and act as if 0.82.1 isn't really a release (which I would have to admit is not far from truth, as it's just "another half of a patch," really). In this case the dot-one is really just a build number, I suppose. We could make the next release 0.84, skip 0.83. That would make 0.84 the 84th release ever of Gaim, but people might get confused. "What happened to 0.83," they would ask. I don't see that as much of a problem. Or, we can take the opportunity to create an entirely new versioning scheme. This would help the people who are constantly confused that 0.x means "doesn't work well" and stay away from Gaim because of it. I would personally consider "Gaim v84", i.e. dropping the 0. altogether. That fits more with the whole "this is the 84th version of Gaim ever," thing, anyway. Opine. -s. |
From: Luke S. <lsc...@us...> - 2004-08-28 17:25:18
|
On Sat, Aug 28, 2004 at 01:19:15PM -0400, Sean Egan wrote: > 0.82.1 officially broke our versioning system. > <snip> > > We could go on, and pretend nothing ever happened. Make the next > release 0.83, and act as if 0.82.1 isn't really a release (which I > would have to admit is not far from truth, as it's just "another half > of a patch," really). In this case the dot-one is really just a build > number, I suppose. > this sounds good. > We could make the next release 0.84, skip 0.83. That would make 0.84 > the 84th release ever of Gaim, but people might get confused. "What > happened to 0.83," they would ask. I don't see that as much of a > problem. i don't think it would be a problem, but i don't like it anyway. > > Or, we can take the opportunity to create an entirely new versioning > scheme. This would help the people who are constantly confused that > 0.x means "doesn't work well" and stay away from Gaim because of it. > I would personally consider "Gaim v84", i.e. dropping the 0. > altogether. That fits more with the whole "this is the 84th version > of Gaim ever," thing, anyway. i like this idea as well. lets do both, ignore 0.82.1, and switch to v83 for the next release. luke > > Opine. > > -s. > |
From: Matthew K. <kel...@po...> - 2004-08-28 18:00:07
|
+1 to v83 On Sat, 2004-08-28 at 13:19, Sean Egan wrote: > 0.82.1 officially broke our versioning system. > > In case you didn't know, our versioning system was entirely > sequential. 0.82 was the 82nd release of Gaim ever. Even though > 0.82.1 isn't much of a "release" on its own, it defies the versioning > system. What to do? > > We could go on, and pretend nothing ever happened. Make the next > release 0.83, and act as if 0.82.1 isn't really a release (which I > would have to admit is not far from truth, as it's just "another half > of a patch," really). In this case the dot-one is really just a build > number, I suppose. > > We could make the next release 0.84, skip 0.83. That would make 0.84 > the 84th release ever of Gaim, but people might get confused. "What > happened to 0.83," they would ask. I don't see that as much of a > problem. > > Or, we can take the opportunity to create an entirely new versioning > scheme. This would help the people who are constantly confused that > 0.x means "doesn't work well" and stay away from Gaim because of it. > I would personally consider "Gaim v84", i.e. dropping the 0. > altogether. That fits more with the whole "this is the 84th version > of Gaim ever," thing, anyway. > > Opine. > > -s. > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- Matthew Keller signat-url: http://mattwork.potsdam.edu/signat-url/ "No one ever says, 'I can't read that ASCII E-mail you sent me.'" |
From: <to...@wc...> - 2004-08-28 18:16:40
|
> +1 to v83 Ditto. > > > On Sat, 2004-08-28 at 13:19, Sean Egan wrote: >> 0.82.1 officially broke our versioning system. >> >> In case you didn't know, our versioning system was entirely >> sequential. 0.82 was the 82nd release of Gaim ever. Even though >> 0.82.1 isn't much of a "release" on its own, it defies the versioning >> system. What to do? >> >> We could go on, and pretend nothing ever happened. Make the next >> release 0.83, and act as if 0.82.1 isn't really a release (which I >> would have to admit is not far from truth, as it's just "another half >> of a patch," really). In this case the dot-one is really just a build >> number, I suppose. >> >> We could make the next release 0.84, skip 0.83. That would make 0.84 >> the 84th release ever of Gaim, but people might get confused. "What >> happened to 0.83," they would ask. I don't see that as much of a >> problem. >> >> Or, we can take the opportunity to create an entirely new versioning >> scheme. This would help the people who are constantly confused that >> 0.x means "doesn't work well" and stay away from Gaim because of it. >> I would personally consider "Gaim v84", i.e. dropping the 0. >> altogether. That fits more with the whole "this is the 84th version >> of Gaim ever," thing, anyway. >> >> Opine. >> >> -s. >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by BEA Weblogic Workshop >> FREE Java Enterprise J2EE developer tools! >> Get your free copy of BEA WebLogic Workshop 8.1 today. >> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click >> _______________________________________________ >> Gaim-devel mailing list >> Gai...@li... >> https://lists.sourceforge.net/lists/listinfo/gaim-devel > -- > Matthew Keller > signat-url: http://mattwork.potsdam.edu/signat-url/ > "No one ever says, 'I can't read that ASCII E-mail you sent me.'" > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel > Topher Manager of Internet Services Cornerstone Broadcasting Cornerstone University ------ perl -e 'print join "", (map({chr(oct("0b"./usr/bin/pine))} (shift =~ /\d{8}/g))),"\n"' \ 010010010010000001110111011010010111001101101000001000000100100100100000011010110110111001100101011101110010000001100010011010010110111001100001011100100111100100101110 |
From: Christian H. <ch...@gn...> - 2004-08-29 08:20:46
|
On Sat, Aug 28, 2004 at 01:19:15PM -0400, Sean Egan wrote: > 0.82.1 officially broke our versioning system. >=20 > In case you didn't know, our versioning system was entirely > sequential. 0.82 was the 82nd release of Gaim ever. Even though > 0.82.1 isn't much of a "release" on its own, it defies the versioning > system. What to do? What about all the 0.59.x versions? 0.82 isn't the 82th release. We broke it long ago. > Or, we can take the opportunity to create an entirely new versioning > scheme. This would help the people who are constantly confused that > 0.x means "doesn't work well" and stay away from Gaim because of it.=20 > I would personally consider "Gaim v84", i.e. dropping the 0. > altogether. That fits more with the whole "this is the 84th version > of Gaim ever," thing, anyway. I'm probably the only person who doesn't like this. It doesn't leave room for future decisions. Say down the road we do move to a standard major.minor.micro system. We may not want to now, and we may not see a reason for it, but we don't know what the project will be like down the road. It could be that none of us are on it, or that we're all still on it. Either way, if we switch to bumping up the major version every release, we block all future decisions in this area. I for one think this is a bad idea. Christian --=20 Christian Hammond <> The Galago Project ch...@gn... <> http://galago.sourceforge.net/ Doesn't expecting the unexpected make the unexpected become the expected? |
From: Andrew S. <gt...@ma...> - 2004-08-29 10:15:12
|
On Sun, 2004-08-29 at 04:20, Christian Hammond wrote: > > Or, we can take the opportunity to create an entirely new versioning > > scheme. This would help the people who are constantly confused that > > 0.x means "doesn't work well" and stay away from Gaim because of it. > > I would personally consider "Gaim v84", i.e. dropping the 0. > > altogether. That fits more with the whole "this is the 84th version > > of Gaim ever," thing, anyway. > > I'm probably the only person who doesn't like this. It doesn't leave > room for future decisions. Say down the road we do move to a standard > major.minor.micro system. We may not want to now, and we may not see a > reason for it, but we don't know what the project will be like down > the road. It could be that none of us are on it, or that we're all > still on it. Either way, if we switch to bumping up the major version > every release, we block all future decisions in this area. I for one > think this is a bad idea. > I agree here. Why not take this time to make the Gaim versioning system more meaningful? As it stands, the micro version has just suddenly been used to represent an important bug fix release. If Gaim moved to just a single number, this would no longer be obvious. Gaim v85 would just look like the next in the series of releases, and could just be ignored by people and distros that aren't upgrade happy. It might also be useful to start using the major versions for goals or other significant events. Maybe Gaim can go 1.?? when the status rewrite is done. Maybe 2.?? when gaim-vv is merged back. This would also help with libgaim. Maybe Gaim 1.?? can be when libgaim is entirely standalone. While Gaim v?? may look great for an instant messaging application, I think it would very strange for a library. Libraries need to have that developer oriented "look." In my personal, entirely aesthetic opinion, the single numbering scheme just looks bad to me. It's like a horrible mix between the marketing hype version numbers (Java jre 1.3 is really Java2) and programs that try to name themselves after years. It'll be right in the middle of this confusingly named category of software. I also think that the single number will be just as misleading to people that don't know about the project as the 0.x system supposedly is now. When you see new major version numbers in software, it usually means something. Netscape 6 is supposed to be 2 better than Netscape 4. It could leave the expectation that something extreme should have changed between Gaim v84 and Gaim v85. In truth, it's ofter much more like the difference between 0.84 and 0.85. The program has improved. Some bugs were fixed. Some features were added. Chances are there was nothing earth shattering that happened here. You often need to go a few releases before Gaim is going to seem that different to you. -- Andrew Sayman <gt...@ma...> |
From: Ryan B. <gai...@ry...> - 2004-08-30 08:09:20
|
> On Sun, 2004-08-29 at 04:20, Christian Hammond wrote: >>> I would personally consider "Gaim v84", i.e. dropping the 0. >> >> I'm probably the only person who doesn't like this. It doesn't leave i'm sorry to say it, but me too. -1 to v84 style. many people and programs expect to get meaningful information from a version number. some people may be confused or misled by v84 style, and many programs will just fail. that seems like a Bad Thing. i *guess* there's value in knowing (more or less) how many gaim releases there have been, even if it's not clear to me what that value is. however, i think there's more value in consistency with the very standard major.minor.patch version number style. -Ryan -- "I do not like all these things that I used to..." -Brad Wolfe |
From: Matthew K. <kel...@po...> - 2004-08-30 13:20:06
|
On Mon, 2004-08-30 at 04:09, Ryan Barrett wrote: > i'm sorry to say it, but me too. -1 to v84 style. I just like it because it's simple and different. In my mind, v84 puts a big middle-finger up at people who obsess over version numbers (oh no, it's not 1.0 so it must suck. Oh no, it's ONLY 1.0 so this v2.0 over here must be better, etc.). Just to ramble a tad more on the general version number topic: In general, version numbers are a direct relationship to goals. Thus, a roadmap exists that says "when these 42 things are done, then we're at version 1. After that, these 35 things yield version 2. The "minor" versions are mapped to feature adds during the release cycle- Thus v1.6 means there have been 6 "for 2.0" features added "since 1". The revision number is for bugfixes. This does not, contrary to some ppl's opinions, handicapping one from making a "quick add" to a version that's not in the roadmap. Either the roadmap can get adjusted or it can be bundled with another roadmapped change in one update. Of course all of this assumes that the engineering monkeys are in control of the versioning and not the marketing monkeys. FOSS projects only occasionally follow this (Mozilla, as one example), as there generally isn't a single grand-vision that one can put their finger on. Programs like Gaim have goals, but are prone to tangential development. This is good as there are tangential events in the IM field, as well as triage when Yahoo/MSN/AOL/whomever decide to do something predatorial (*remember the old AOL checksum wars*). Something to think about. I'm not preaching, just informing. -- Matthew Keller signat-url: http://mattwork.potsdam.edu/signat-url/ "No one ever says, 'I can't read that ASCII E-mail you sent me.'" |
From: Brian B. <boc...@gm...> - 2004-08-30 16:00:18
|
On Mon, 30 Aug 2004 09:21:40 -0400, Matthew Keller <kel...@po...> wrote: > On Mon, 2004-08-30 at 04:09, Ryan Barrett wrote: > > i'm sorry to say it, but me too. -1 to v84 style. > > I just like it because it's simple and different. In my mind, v84 puts a > big middle-finger up at people who obsess over version numbers (oh no, > it's not 1.0 so it must suck. Oh no, it's ONLY 1.0 so this v2.0 over > here must be better, etc.). While I don't question the need to give the big middle-finger to people occaisonally, I don't think this would be one. I think going to a numbering system that means something significant to users would be useful. After all, v84 or v0.84 might mean that it's the 84 release; but really - do you consider that knowledge relevant? Does anyone think that knowing the release number is more important as knowing "this is the latest stable release"? I realize some people do compare version numbers unrealistically - aka, if Kopete is v2.0, then gaim at v1.0 must be worse - but that is NOT a good argument to deny the realistic users pertinent information. This example is going to be a bit rambling, but I feel is a textbook case for major.minor versioning. For example, let's say the lead developers put out some goals to work towards - the status rewrite, for example. I think all new major codework inherently has some bugs in it; if one would release a version with some major work in it as just v0.85, one might assume that it is MORE stable than v0.84. In reality, due to the major codework, it might be less stable. We have no way to mark this. So, let's say some package managers/people realize this - some people are always going to be interested in stability over bleeding edge - and keep there distro on v0.84. If a big security hole is found, how does one address this? Do you release v0.86 to address this - if so, does the patch cover v0.84 or v0.85? If the release 0.86 patches the old codebase, then what the heck did you do that major coding in v0.85 for? If you patch 0.85, you might leave most of your users (who are on 0.84) hanging in the wind. I release this project is a hobby, but forcing your users to upgrade from stable to unstable just to get a security patch is kind of rude. I would say at least a versioning system that allows for a development/stable version to be floating about would be desirable. This allows for people who want all the bleeding-edge features to have a version of gaim, and for people who want stability and no-breakage-no-matter-what to have their version of gaim. Just my thoughts, Brian B |
From: Ethan B. <ebl...@cs...> - 2004-08-30 16:33:21
|
Brian Bockelman spake unto us the following wisdom: > I would say at least a versioning system that allows for a > development/stable version to be floating about would be desirable. > This allows for people who want all the bleeding-edge features to > have a version of gaim, and for people who want stability and > no-breakage-no-matter-what to have their version of gaim. While that might be a desirable thing, it overlooks the fact that there are no stable and unstable releases of Gaim ... the intent is that every release is largely stable. Maintaining multiple branches is a nontriv- ial job, and we as developers have come to rough consensus that our time is better spent working always on general forward progress rather than sometimes on bugfixes only and sometimes on new features. I think that we might generally benefit from a tad more release engi- neering, but I do not think that any of us have the time or desire to maintain two parallel branches for any length of time. Another important fact to consider is that "no-breakage-no-matter-what" is completely unreasonable to expect from Gaim; protocol changes, for one, make this impossible. With the pace of Gaim development, backport- ing such critical fixes to a version even a few months old can rapidly become a time-consuming task. Obviously maintaining a stable and an unstable branch _can_ be done, as many projects do so. However, it requires developer time and effort, of which we do not seem to have a surplus. Ethan --=20 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 |
From: Luke S. <lsc...@us...> - 2004-08-30 16:59:42
|
On Mon, Aug 30, 2004 at 12:00:14PM -0400, Brian Bockelman wrote: > On Mon, 30 Aug 2004 09:21:40 -0400, Matthew Keller <kel...@po...> wrote: > > On Mon, 2004-08-30 at 04:09, Ryan Barrett wrote: > > > i'm sorry to say it, but me too. -1 to v84 style. > > > > I just like it because it's simple and different. In my mind, v84 puts a > > big middle-finger up at people who obsess over version numbers (oh no, > > it's not 1.0 so it must suck. Oh no, it's ONLY 1.0 so this v2.0 over > > here must be better, etc.). > > While I don't question the need to give the big middle-finger to > people occaisonally, I don't think this would be one. I think going > to a numbering system that means something significant to users would > be useful. After all, v84 or v0.84 might mean that it's the 84 > release; but really - do you consider that knowledge relevant? Does it is more representative of what we are doing now than saying 0.83 is, and it also provides a better picture of the way things actually work in gaim development, since we haven't had split code bases since the 0.59.x days when we were migrating to 0.60. > anyone think that knowing the release number is more important as > knowing "this is the latest stable release"? I realize some people do > compare version numbers unrealistically - aka, if Kopete is v2.0, then > gaim at v1.0 must be worse - but that is NOT a good argument to deny > the realistic users pertinent information. > its also not good to make them thing there is more info in the version number than really is there. > This example is going to be a bit rambling, but I feel is a textbook > case for major.minor versioning. > For example, let's say the lead developers put out some goals to work > towards - the status rewrite, for example. I think all new major something we have been VERY VERY bad about doing. just look at our rather pitiful attempts at even creating a todo list. > codework inherently has some bugs in it; if one would release a > version with some major work in it as just v0.85, one might assume > that it is MORE stable than v0.84. In reality, due to the major > codework, it might be less stable. We have no way to mark this. So, in reality, gaim hasn't had more than a handful of truely stable releases since well before i joined the project, each release has had some significant issues for at least a subset of users, though most releases have worked acceptably well for most users. also in reality, many of the releases we have gone into thinking it would be very stable have had significant issues in use-cases we simply never hit. > let's say some package managers/people realize this - some people are > always going to be interested in stability over bleeding edge - and > keep there distro on v0.84. If a big security hole is found, how does yes, we have some users doing this already. and then they submit bug reports and feature requests for things that they would have had fixed and/or implemented if they had upgraded. this is particularly the case with debian stable (shipping 0.59.x), mdk (shipping 0.75, a particularly bad release), and fresh cd installs (which by very nature are out of date with a project that releases even once a month). > one address this? Do you release v0.86 to address this - if so, does > the patch cover v0.84 or v0.85? If the release 0.86 patches the old > codebase, then what the heck did you do that major coding in v0.85 > for? If you patch 0.85, you might leave most of your users (who are > on 0.84) hanging in the wind. I release this project is a hobby, but on the other hand, by forcing them to upgrade we stop hearing about issues that have been solved for months. oh and did i mention that some protocols, like yahoo of late, change and that the old versions simply won't work? > forcing your users to upgrade from stable to unstable just to get a > security patch is kind of rude. > i've always considered out job to get the new versions out the door, not to maintain old versions. if you want to keep the same version and get patches to it, look to someone with time to do that, like say your distro. > I would say at least a versioning system that allows for a > development/stable version to be floating about would be desirable. see the above for some hints as to why differentiating a "development" and a "stable" version are bad. > This allows for people who want all the bleeding-edge features to have > a version of gaim, and for people who want stability and > no-breakage-no-matter-what to have their version of gaim. > as mentioned above, the changing nature of the protocols will ENSURE that your "no-breakage-no-matter-what" version WILL break. lets take a look here: yahoo won't work older than 0.79. msn won't work older than 0.69. gadu-gadu has changed the protocol sometime in the last 4 versions (forget exactly when), several years ago you HAD to use cvs to stay connected to aim (that only lasted for a few months). any of these events can and probly will happen again. in summary, the biggest issues i see are: 1)maintaining old versions takes time and effort. who is going to do this? and more importantly when? given time and ability to backport the fixes and patches, i _can_ make the requisite changes to the bug tracking to support that side of things. though doing so would be considerably easier in a better tracker than sf provides, but i'm probly not the one to try to keep those old versions patched. 2)what makes a release stable? i would argue that _at most_ two releases since 0.60 would qualify. and that only if you carefuly match that code against the "right" version of gtk. NO win32 release would qualify as stable. CERTAINLY "stable" on unix and win32 would and will continue to vary. 3)how do we publish a roadmap when things like status get delayed indefinitally, and the stuff going into new versions, some of it very significant, are things we wake up one morning and code, or find a patch for in our inboxes? luke > Just my thoughts, > > Brian B > |
From: Luke S. <lsc...@us...> - 2004-08-30 17:42:56
|
On Mon, Aug 30, 2004 at 01:16:45PM -0400, Brian Bockelman wrote: > Some very good points - gaim DOES have several unique issues, such as > protocols changing "under our feet" that make stable releases - well - > inherently unstable. But I still think that the ability to do what we > have already done - release something out-of-schedule such as 0.82.1 - > is important. Perhaps the solution is just to say that v0.82.minor is > for immediate bugfixes, and that's ok. Truthfully, it's something > that I would like to hear from the lead devel on, and I'd be fine > doing what he says... > > Anyhow, one of your points I found particularly troubling... > > > > > something we have been VERY VERY bad about doing. just look at our > > rather pitiful attempts at even creating a todo list. > > > > Why is this exactly? I don't know any history behind this (I haven't > been on this mailing list for long), so I don't know if this has been > extensively discussed. However, if I knew what goals there were, I > would be inclined to help out. I, for one, can contribute coding and > / or testing time, but don't really know where help is needed. If > there was a todo list, it would be easier for me to help out. its happened for a number of reasons. all of them fixable by better discipline on our part. 1)we don't tend to remember to add things as they get discussed over im/chat. we are im developers, we tend to use it to communcate between ourselves, both in #gaim on irc and not. things discussed here only sometimes make it into the todo file 2)we tend to forget to mark stuff as done as it is finished, this is particularly the case when we accept patches. 3)some things such as the status re-write that we all know is badly needed (the current status model is aim-centric and does not have the ability to adequately support the more flexible status features of other protocols) do not fit easily into a todo item. how do you describe a change that affects nearly everything, AND that isn't fully designed or thought out as a series of goals? i've attempted to get a todo list used several times, i started by updating the flatfile todo that was there when i joined the project, and when i realized that was a lost cause (it was too long to easily find things in), i moved to a .todo setup with the devtodo program, and have tried that on and off since. Christian wrote a script to update a todo on the website based on its contents, but neither the .todo or the website get updated nearly enough. > > Speaking of which, do you know how or where I could help out in the project? the biggest isolatable needs right now are 1)for someone to go over the connection and disconnection code with a fine-toothed comb and figure out why its failure ends in a segfault more often than it should. 2)go over the proxy support with a full set of carpenter's tools and make it work. #2 is splitable into sub-needs for each kind of proxy you can envision. the next biggest need is for someone to go through the bug database, pick the one that annoys them most, and submit a patch for it. this is listed second and not first only because its the harder one to pick up and run with. the biggest need after that is for help with Christian's status re-write. we are discussion whether to keep that as a separate tree or to move it into main cvs now (its come up in #gaim several times recently, and i keep bugging sean about it) after that, privacy will need similar work to what Christian is doing with status. after both privacy and status, we will be ready to finish the long term effort at creating a libgaim somewhere in there we should look at some abstraction that would make msn with its lack of distinction between a chat (multiple people) and a conversation (exactly two) sane. in doing so, we should make yahoo conferences (analogous to msn chats, while yahoo chats are a more standard concept of chats) sane. also somewhere in there, we need a ui to insert random tags into a gtkimhtml. its not reasonable to have key-strokes or buttons for every possible tag that some of the more flexible protocols (aim) support, its even less reasonable to try to have a mix of wysiwyg and hand-typed tags. esp. as most tags aren't used all that often. luke |
From: Bleeter Y. <gai...@si...> - 2004-08-30 22:08:05
|
Ryan Barrett wrote: >> On Sun, 2004-08-29 at 04:20, Christian Hammond wrote: >> >>>> I would personally consider "Gaim v84", i.e. dropping the 0. >>> >>> >>> I'm probably the only person who doesn't like this. It doesn't leave >> > > i'm sorry to say it, but me too. -1 to v84 style. Personally, I didn't see it hurting Solaris when they moved from 2.6 to Solaris 7. A little bit of marketplace confusion initially, leading to a position where 2.7 or 2.8 were not considered 'minor' releases. So maybe, for no apparent reason, I'd vote for 8.3, 8.4, 8.4.1, etc. P. |
From: Ka-Hing C. <ja...@ja...> - 2004-08-31 07:03:23
|
On Mon, 2004-08-30 at 15:07, Bleeter Yaluser wrote: > Personally, I didn't see it hurting Solaris when they moved from 2.6 to > Solaris 7. A little bit of marketplace confusion initially, leading to a > position where 2.7 or 2.8 were not considered 'minor' releases. So > maybe, for no apparent reason, I'd vote for 8.3, 8.4, 8.4.1, etc. If gaim is to follow an existing versioning scheme, let's not use SUN's as an example. I mean, they are the ones who came up with Java 5 > J2SE 1.5 > J2SE 1.4 > ... > Java 1.2. Of course, unless the vote is for G84IM, in which case I may agree. -khc |
From: Stu T. <st...@no...> - 2004-08-31 17:55:11
|
On Sat, 2004-08-28 at 13:19, Sean Egan wrote: > Or, we can take the opportunity to create an entirely new versioning > scheme. I suggest adding the positive square root of the natural logarithm of the sum of the number of lines added and removed since the previous release to generate the next version number. Ignoring 0.82.1 because it wasn't really a release, it is simple to determine what the version is at release time: v="0.82" ; echo v`cvs diff -udp -rv${v/./_}|grep '^[-+]'|wc -l|perl -ne "print ${v}+sqrt(log())"|sed 's/\./_/'` Regards, Stu. |
From: Rob F. <ga...@ro...> - 2004-09-01 16:52:25
|
v84.0! ;) It really is a weird decision to make because no matter what you decide, there will be people that are confused. Sean Egan wrote: >0.82.1 officially broke our versioning system. > >In case you didn't know, our versioning system was entirely >sequential. 0.82 was the 82nd release of Gaim ever. Even though >0.82.1 isn't much of a "release" on its own, it defies the versioning >system. What to do? > >We could go on, and pretend nothing ever happened. Make the next >release 0.83, and act as if 0.82.1 isn't really a release (which I >would have to admit is not far from truth, as it's just "another half >of a patch," really). In this case the dot-one is really just a build >number, I suppose. > >We could make the next release 0.84, skip 0.83. That would make 0.84 >the 84th release ever of Gaim, but people might get confused. "What >happened to 0.83," they would ask. I don't see that as much of a >problem. > >Or, we can take the opportunity to create an entirely new versioning >scheme. This would help the people who are constantly confused that >0.x means "doesn't work well" and stay away from Gaim because of it. >I would personally consider "Gaim v84", i.e. dropping the 0. >altogether. That fits more with the whole "this is the 84th version >of Gaim ever," thing, anyway. > >Opine. > >-s. > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click >_______________________________________________ >Gaim-devel mailing list >Gai...@li... >https://lists.sourceforge.net/lists/listinfo/gaim-devel > > > > |
From: Nathan W. <fac...@fa...> - 2004-09-01 22:57:33
|
Rob Flynn wrote: > v84.0! > > ;) > > It really is a weird decision to make because no matter what you decide, > there will be people that are confused. I have a versioning system that could quite possibly satisfy everyone: Our next version should be (if my figuring is correct): 2004.09.16 Advantages: - It has a major, a minor, and a micro part (not that they're particularly useful) - It keeps us from ever having a "Gaim 95" "Gaim 98" (these really would confuse idiot users) - It makes it quite obvious that any given release of Gaim is really just a CVS snapshot that we let settle a little bit - I had more advantages thought up when I started typing this, but I seem to have forgotten them now If that doesn't make everyone happy, then I have another suggestion: Lets make the next release Gaim 1.0.0 No really, follow my reasoning for a minute: - We've avoided a Gaim 1.0 because we're afraid that it will fail peoples' expectations of a 1.0 release ( - We have never really cared about peoples' expectations - Gaim is stable for me, for rob, for sean, for mark, for ethan, for luke.... Last I checked, whenever someone comes into #gaim threatening to use something else if we don't do XYZ, our response is something along the lines of "Go ahead. We do this for us, if it's useful to you, that's fine. If it's not, that's fine too" After 1.0.0, I think we should let our version numbers go up at an astronomical rate, appropriately: Bump the first number if we change anything that would make any plugin that's already compiled (or written, in the case of perl and tcl) not work. This will go up a lot, at least in the near future. Bump the second number if we change something that would cause a plugin compiled against X.Y.0 to fail to work with X.Y-1.Z Bump the third number if we don't do either of the above (we fix bugs, don't change or add to the ABI). Truth be told, I like my second suggestion a lot better, both for it's future benefits, and its "haha! we made a 1.0, and it's nothing special!" attitude. Flame on, Nathan |
From: Matthew K. <kel...@po...> - 2004-09-02 01:28:38
|
I have always liked date-stamp based version numbers. Not "Office 95 version 12.15.21 Build 2034239238729" shit, but useful dates as you outlined (2004.09.16). It also provides my requisite "middle finger at those who obsess over version numbers". :) +1 On Wed, 2004-09-01 at 18:57, Nathan Walp wrote: > Rob Flynn wrote: > > v84.0! > > > > ;) > > > > It really is a weird decision to make because no matter what you decide, > > there will be people that are confused. > > I have a versioning system that could quite possibly satisfy everyone: > > Our next version should be (if my figuring is correct): 2004.09.16 > > Advantages: > - It has a major, a minor, and a micro part (not that they're > particularly useful) > - It keeps us from ever having a "Gaim 95" "Gaim 98" (these really would > confuse idiot users) > - It makes it quite obvious that any given release of Gaim is really > just a CVS snapshot that we let settle a little bit > - I had more advantages thought up when I started typing this, but I > seem to have forgotten them now > > > If that doesn't make everyone happy, then I have another suggestion: > > Lets make the next release Gaim 1.0.0 No really, follow my reasoning > for a minute: > > - We've avoided a Gaim 1.0 because we're afraid that it will fail > peoples' expectations of a 1.0 release ( > - We have never really cared about peoples' expectations > - Gaim is stable for me, for rob, for sean, for mark, for ethan, for > luke.... Last I checked, whenever someone comes into #gaim threatening > to use something else if we don't do XYZ, our response is something > along the lines of "Go ahead. We do this for us, if it's useful to you, > that's fine. If it's not, that's fine too" > > After 1.0.0, I think we should let our version numbers go up at an > astronomical rate, appropriately: > > Bump the first number if we change anything that would make any plugin > that's already compiled (or written, in the case of perl and tcl) not > work. This will go up a lot, at least in the near future. > > Bump the second number if we change something that would cause a plugin > compiled against X.Y.0 to fail to work with X.Y-1.Z > > Bump the third number if we don't do either of the above (we fix bugs, > don't change or add to the ABI). > > > Truth be told, I like my second suggestion a lot better, both for it's > future benefits, and its "haha! we made a 1.0, and it's nothing > special!" attitude. > > Flame on, > Nathan > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel -- Matthew Keller signat-url: http://mattwork.potsdam.edu/signat-url/ "No one ever says, 'I can't read that ASCII E-mail you sent me.'" |
From: Ka-Hing C. <ka...@ja...> - 2004-09-02 01:58:03
|
On Wed, 2004-09-01 at 15:57, Nathan Walp wrote: > Bump the first number if we change anything that would make any plugin > that's already compiled (or written, in the case of perl and tcl) not > work. This will go up a lot, at least in the near future. > > Bump the second number if we change something that would cause a plugin > compiled against X.Y.0 to fail to work with X.Y-1.Z Sometimes plugins are broken without knowing until after release. What should be done in this case? It would probably be easier if "not work" is changed to "not compile". For perl and tcl, since a "not working" plugin tend not to crash gaim, I say let's not worry about them too much. Following the modified proposal, bumping the first number would mean: 1) exported function(s) has been removed, renamed 2) definition of exported struct(s) changed bumping the second number would mean: 1) new exported function(s) 2) new exported struct(s) Wouldn't that be similar to what GTK is doing (except that they bump the second number once and call it unstable, then bump it again and call it stable)? The downside is, no one really knows what the next version will be called until the freeze. But then with the YYYY.MM.DD scheme, no one knows the version until the day it's released. I think Nathan's second proposal is better than the first, since it gives the users/plugin writers a way to know if the plugin needs to be updated. The plugin api can also be modified to not load certain plugins if they are outdated. The question is, will gaim be /. again when 1.0 comes out? -khc |
From: Ka-Hing C. <ja...@ja...> - 2004-09-02 01:59:09
|
On Wed, 2004-09-01 at 15:57, Nathan Walp wrote: > Bump the first number if we change anything that would make any plugin > that's already compiled (or written, in the case of perl and tcl) not > work. This will go up a lot, at least in the near future. > > Bump the second number if we change something that would cause a plugin > compiled against X.Y.0 to fail to work with X.Y-1.Z Sometimes plugins are broken without knowing until after release. What should be done in this case? It would probably be easier if "not work" is changed to "not compile". For perl and tcl, since a "not working" plugin tend not to crash gaim, I say let's not worry about them too much. Following the modified proposal, bumping the first number would mean: 1) exported function(s) has been removed, renamed 2) definition of exported struct(s) changed bumping the second number would mean: 1) new exported function(s) 2) new exported struct(s) Wouldn't that be similar to what GTK is doing (except that they bump the second number once and call it unstable, then bump it again and call it stable)? The downside is, no one really knows what the next version will be called until the freeze. But then with the YYYY.MM.DD scheme, no one knows the version until the day it's released. I think Nathan's second proposal is better than the first, since it gives the users/plugin writers a way to know if the plugin needs to be updated. The plugin api can also be modified to not load certain plugins if they are outdated. The question is, will gaim be /. again when 1.0 comes out? -khc |
From: Nathan W. <fac...@fa...> - 2004-09-02 04:20:43
|
Ka-Hing Cheung wrote: > On Wed, 2004-09-01 at 15:57, Nathan Walp wrote: > >>Bump the first number if we change anything that would make any plugin >>that's already compiled (or written, in the case of perl and tcl) not >>work. This will go up a lot, at least in the near future. >> >>Bump the second number if we change something that would cause a > > plugin > >>compiled against X.Y.0 to fail to work with X.Y-1.Z > > > Sometimes plugins are broken without knowing until after release. > What should be done in this case? It would probably be easier if "not > work" is changed to "not compile". For perl and tcl, since a "not > working" plugin tend not to crash gaim, I say let's not worry about them > too much. > > Following the modified proposal, bumping the first number would mean: > 1) exported function(s) has been removed, renamed > 2) definition of exported struct(s) changed > bumping the second number would mean: > 1) new exported function(s) > 2) new exported struct(s) This is EXACTLY what I meant. Aside from the wanting-to-have-the-nth-release-version-numbers argument, I don't see any good reason not to go this route. > > Wouldn't that be similar to what GTK is doing (except that they bump the > second number once and call it unstable, then bump it again and call it > stable)? > > The downside is, no one really knows what the next version will be > called until the freeze. But then with the YYYY.MM.DD scheme, no one > knows the version until the day it's released. Well, if we're at X.Y.Z, then we'll know it will be at least X.Y.Z+1, and we rarely do anything that would require an X or Y bump right before a freeze. > I think Nathan's second proposal is better than the first, since it > gives the users/plugin writers a way to know if the plugin needs to be > updated. The plugin api can also be modified to not load certain plugins > if they are outdated. Yes. As part of the first bump of X (to 1) I would want to change the plugin API to ditch the PRPL api number, and fix the plugin api to load the plugin only if X is equal to what I was compiled against, and Y is at least what I was compiled against. > > The question is, will gaim be /. again when 1.0 comes out? Who cares? -Nathan |
From: Dale K. <da...@da...> - 2004-09-01 23:56:08
|
Been lurking here a while and thought I'd add my 2c... Why not call the next release GaimXP and from then on release SP1.. SP2 etc *ducks* On a more serious note, why not call the next release 1.83. Then in 17 releases time (~1yr?) you could be ready for 2.0. This would keep the package maintainers happy and accurately refelct the "production" quality of the software. You would lose the nth release of Gaim but as others have said this isn't too much of a problem as it can be tracked elsewhere. |