Yeah, noone is active, noone wants to do anything, and that sucks... And I'm tired of being the one who has to do everything or the one who needs to motivate everyone.. Thankfully, I feel like Phil is a big big help to me as he is very dedicated to the project. The 0.97 release should be done shortly, we want to get it out as soon as possible.. the TODO list is huge, we have many things to fix... but as I said lately on a PM with someone : "when did we ever release a version of aMSN with no bugs?".. I think trying to get 0.97 as perfect as possible is the cause of this delay, probably because we thought "this is the last release, so let's make it as good as possible", but it can't be doable, there will always be stuff coming in, always new bugs discovered... So I decided to make the release, as is.. just go through the list of bugs one last time, see if anything is *major critical*, if yes, fix it, take an hour or two to fix anything left, then get ready to release... I'll do this tomorrow or next week depending on availability.
KaKaRoTo On Mon, Dec 17, 2007 at 04:33:25PM +0100, Harry Vennik wrote: > Hi, > > This is certainly a good idea, but it can only work when the aMSN team is > more active, and thus more productive. aMSN 0.97 final is getting so late > just because there is nobody with enough time to make the release ready. > Youness said in another mail he *maybe* has the time to do it shortly... > > So really, I'd like this to be done, but I think it just isn't possible, > unless we get some people in the team who have enough time to keep things > going... > > Harry > > Op 17-dec-2007, om 13:03 heeft square87 het volgende geschreven: > >> Hi >> I just want to share a my idea. >> For me, aMSN releasing is too slow. >> I'd like to have the following release: aMSN 0.VERSION.FEATURE.BUGFIX >> >> I think that we'll never have aMSN 1 but maybe directly aMSN 2, so doesn't >> consider the 0 in aMSN 0.etc... >> >> Think that: >> set version $actualversion >> set feature 0 >> set bugfix 0 >> >> I suggest: >> When we want a new version just decide what that version should have >> >> if the feature is also compatible with the actual version so release: >> incr feature >> set name_release "0.$actualversion.$feature" >> >> if we fix a bug that it's both in actual version and in svn release: >> incr bugfix >> set name_release 0.$actualversion.$feature.$bugfix >> >> -------- >> For example: >> IF in aMSN 0.98SVN we add "plugin manager" and that code is compatible >> with aMSN 0.97 so put that code in aMSN 0.97.1 >> >> IF you find a solution for a bug that it's also in aMSN 0.97: release aMSN >> 0.97.0.1 >> >> If you want to do both things: >> but you first add plugin manager and then that fixbug, release: aMSN >> 0.97.1.1 >> else release: aMSN 0.97.1 >> >> -------- >> I am not saying that for every bugfix release a new sub-version, but we >> can do two things: >> 1) Release a sub-version every moths. >> 2) Release a sub-version when we fix a critical bug, or when we fixed a >> TOT bugs, or when we add some feature (with a particular "priority") or >> whatever... >> >> ------- >> For example i am writing the code to show notify window with canvas style, >> but if i don't have time to do that and it's not a goal for aMSN 0.97 that >> code should go in aMSN0.98SVN but if it's also compatible for aMSN 0.97 so >> release, after a while, aMSN 0.97.1, without say to users "use svn" that >> it could be full of bugs or uncompleted codes or whatever. >> >> I am saying that because: >> 1) we have to compare with other projects >> 2) an user cannot wait 1 or 2 years for a new version or download an SVN >> that could be unstable. >> >> Many users use aMSN because we have webcam support but who downloaded aMSN >> 0.97RC1 has the $brightness bug that was fixed moths ago... ( seven ( 7 ) >> moths ago...). How many people download in 7 moths aMSN 0.97RC1 ? without >> considering that it's in the repo of *ubuntu. And How many bugs was been >> resolved in 7 moths? and how many thread we have in the forum that talk >> about bugs in aMSN 0.97 that they are already resolved? >> That's the reason cause i said: for me, aMSN releasing is too slow. >> but it's also counterproductive, and in seven moths we doesn't have an >> RC2... >> >> Then i think that have a release history is also a "good imagine" for >> aMSN. >> >> Just my opinion. I'd like to have yours. >> Sorry for my English. >> Thanks, bye >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services >> for just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace_______________________________________________ >> Amsn-devel mailing list >> Amsn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/amsn-devel > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services > for just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
