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
