download versions and changelog
Ademar de Souza Reis Jr.
I noticed there is only one version for download, and it's 1.0svn.
There are two reasons why it's wrong:
1. There should be a stable version available for download (1.0svn by
definition is not stable... it should be either 1.0 or 1.1);
2. There's no way to know from which SVN revision 1.0svn was extracted;
Besides, it would be nice to keep at least one previous stable version
available for download (old versions could be extracted from SVN, but
it's usually good to have access to the previous tarball in case of
regressions).
Finally, while thinking about (2), I noticed we don't distribute a
ChangeLog with our tarballs.. We should either create a high-level one
by hand stored on SVN or have a dist-hook that creates it based on svn
log; I like the idea of a hand-made ChangeLog, but it requires more
discipline from the developer. A dist-hook will be automagic, but a
robust dist-hook rule may not be trivial. What do you think?
Best regards,
- Ademar
--
Ademar de Souza Reis Jr. <ade...@ademar.org>
http://www.ademar.org/
http://blog.ademar.org/
^[:wq!
caval...@gmail.com
I had just read your message and I'm a bit confused about it.
So, let me question you:
1. The primary concern here is about naming convention (the '1.0svn')
or about
providing access to a 'stable' version of software? I see them as 2
different issues.
2. Again, assuming that is a naming issue, I think we can relate the
repository
tagged versions X the tarball names. Maybe there is a better way to
handle it... any ideas?
The project site do enable access to previous releases of Amora, just
select downloads
and search for 'deprecated'.
In case of regression, we need just to change the tags of available
files (from 'deprecated' back
to 'featured').
Finally, about changelogs, we should provide them together with the
amora tarballs. I think
since 100% of commits do have commented logs, we can use the svn2cl
tool to automatize
changelog creation.
Not only that, but the project roadmap (http://code.google.com/p/amora/
wiki/roadmap) provides
some big picture about the main features of each project release.
Obviously, we can always
improve that as long that it doesn't poses an ordeal for day-to-day
development.
Best regards
Adenilson
Ademar de Souza Reis Jr.
>
> Ademar
>
> I had just read your message and I'm a bit confused about it.
>
> So, let me question you:
>
> 1. The primary concern here is about naming convention (the '1.0svn')
> or about
> providing access to a 'stable' version of software? I see them as 2
> different issues.
1.0svn implies it's a version extracted from svn. OK, it may not imply
it's unstable, but it's not a proper stable release, it's a
"development snapshot", so it should not be the featured download
option.
Hmm... I think I see your point... Correct me if I'm wrong, but you
never released amora-server-1.0, you forgot to change the version
inside configure.ac before making the release and therefore the
tarball was created as 1.0svn... :-)
Traditionally, projects have something in their version to identify
it's a development version while they're under development, but it's
part of the task of the release-manager to change it before making a
official release and then change it back as soon as the release is
made (it's common to have branch for this kind of tasks, but branches
sux on svn).
>
> 2. Again, assuming that is a naming issue, I think we can relate the
> repository
> tagged versions X the tarball names. Maybe there is a better way to
> handle it... any ideas?
Traditionally, svn snapshots include the date (YYYYMMDD) or the svn
revision in the tarball. Official releases should have a proper
release-notes (news on the website, e-mail on the devel list, etc) and
a tag on SVN.
>
> The project site do enable access to previous releases of Amora, just
> select downloads
> and search for 'deprecated'.
Oh, /me google-code newbie. :-)
>
> In case of regression, we need just to change the tags of available
> files (from 'deprecated' back
> to 'featured').
It's up to the user to decide that, not the developer. If you find a
bug, you fix it and release a new version, but it's always nice to let
at least two versions available for download, so that the users may
run tests and notify you of regressions.
>
> Finally, about changelogs, we should provide them together with the
> amora tarballs. I think
> since 100% of commits do have commented logs, we can use the svn2cl
> tool to automatize
> changelog creation.
The challenge is the automake dist-hook... I still have to do a better
search, but the hooks I've found so far are not robust.
>
> Not only that, but the project roadmap (http://code.google.com/p/amora/
> wiki/roadmap) provides
> some big picture about the main features of each project release.
> Obviously, we can always
> improve that as long that it doesn't poses an ordeal for day-to-day
> development.
I'm OK with the roadmap, my concern is because users may get amora
directly from distributions or other sources, thus a proper ChangeLog
(and a consistent release version) are important (actually, I found
these problems while adding the 1.0 version to the official mandriva
repositories).
Thanks!
Thiago Marcos P. Santos
>
> On Jan 23, 2008 6:28 PM, <caval...@gmail.com> wrote:
> >
> > Ademar
> >
> > I had just read your message and I'm a bit confused about it.
> >
> > So, let me question you:
> >
> > 1. The primary concern here is about naming convention (the '1.0svn')
> > or about
> > providing access to a 'stable' version of software? I see them as 2
> > different issues.
>
> 1.0svn implies it's a version extracted from svn. OK, it may not imply
> it's unstable, but it's not a proper stable release, it's a
> "development snapshot", so it should not be the featured download
> option.
>
> Hmm... I think I see your point... Correct me if I'm wrong, but you
> never released amora-server-1.0, you forgot to change the version
> inside configure.ac before making the release and therefore the
> tarball was created as 1.0svn... :-)
The Debian Etch package of Amora Server was made with the correct
version number. The configure.ac was manually edited and the version
number was changed from 1.0svn to just 1.0.
caval...@gmail.com
> 1.0svn implies it's a version extracted from svn. OK, it may not imply
> it's unstable, but it's not a proper stable release, it's a
> "development snapshot", so it should not be the featured download
> option.
remarks are valuable to make amora naming convention more compliant
with default standards. Next time we will remove the 'svn' from
tarballs.
Just a minor note: it is better to have a not perfect release than
have none.
e.g. the bug in Amora client SIS package was only discovered thanks to
the public release (after nearly 10 days of a beta release).
> Hmm... I think I see your point... Correct me if I'm wrong, but you
> never released amora-server-1.0, you forgot to change the version
> inside configure.ac before making the release and therefore the
> tarball was created as 1.0svn... :-)
>
> Traditionally, projects have something in their version to identify
> it's a development version while they're under development, but it's
> part of the task of the release-manager to change it before making a
> official release and then change it back as soon as the release is
> made (it's common to have branch for this kind of tasks, but branches
> sux on svn).
>
provided by google code? Is there another alternative that don't suck
(e.g. sourceforge)?
> Traditionally, svn snapshots include the date (YYYYMMDD) or the svn
> revision in the tarball. Official releases should have a proper
> release-notes (news on the website, e-mail on the devel list, etc) and
> a tag on SVN.
tarball name). Not only that, but I think it doesn't make sense
provide svn snapshots because:
a) The svn version must be *always* compilable (and whoever breaks the
code will need to pay some snacks to the team...)
b) The user that wants to live in the 'edge', can just checkout the
code from repository
Concerning the items that you had written, let's see the list:
- news on website ........ ok
- email on devel-list ..... no (but we have only 4 active developers,
do we need an email in devel list?
If I recall correctly, I had contacted each developer individually to
announce the plan to release amora within few days)
- email on user-list ....... ok
- svn tag ....................... ok
some pluses:
- release note on freshmeat ....... ok
- release note on forum nokia ..... ok
- release note on br-linux ............ ok
- contact Fedora .......................... ok
> Oh, /me google-code newbie. :-)
>
> It's up to the user to decide that, not the developer. If you find a
> bug, you fix it and release a new version, but it's always nice to let
> at least two versions available for download, so that the users may
> run tests and notify you of regressions.
>
release 'featured' just for the sake of making it available (i.e. the
bugged amora client SIS is *still* available for download, but is not
featured in the project's website. What I had done was to release a
1.0-1 version with packaging fixed).
When it makes sense, yes it can be done (e.g. when I released amora
0.8, I kept client version 0.7 for older cellphones 'featured' since I
had not have time to test it properly in S60 2ed devices).
Contrast that with Amora 1.0, which had being well tested in both S60
3ed and 2ed devices.
>
> The challenge is the automake dist-hook... I still have to do a better
> search, but the hooks I've found so far are not robust.
>
have an autotools wizard (you) in the team!
:-)
>
> I'm OK with the roadmap, my concern is because users may get amora
> directly from distributions or other sources, thus a proper ChangeLog
> (and a consistent release version) are important (actually, I found
> these problems while adding the 1.0 version to the official mandriva
> repositories).
>
bundle a changelog with the tarball and remove the nefarious 'svn'
suffix in the package name (and the site project already hosts older
version releases), what else is missing?
Best regards
Adenilson
Ademar de Souza Reis Jr.
>
> Ademar
>
> > 1.0svn implies it's a version extracted from svn. OK, it may not imply
> > it's unstable, but it's not a proper stable release, it's a
> > "development snapshot", so it should not be the featured download
> > option.
>
> I was not aware of such subtleties of software releases, and your
> remarks are valuable to make amora naming convention more compliant
> with default standards. Next time we will remove the 'svn' from
> tarballs.
>
> Just a minor note: it is better to have a not perfect release than
> have none.
> e.g. the bug in Amora client SIS package was only discovered thanks to
> the public release (after nearly 10 days of a beta release).
Sure, and the good feedback and interest amora is receiving is proof
of that. :-)
>
> > Hmm... I think I see your point... Correct me if I'm wrong, but you
> > never released amora-server-1.0, you forgot to change the version
> > inside configure.ac before making the release and therefore the
> > tarball was created as 1.0svn... :-)
>
> Yep, same again. I will improve it in next time.
>
> > Traditionally, projects have something in their version to identify
> > it's a development version while they're under development, but it's
> > part of the task of the release-manager to change it before making a
> > official release and then change it back as soon as the release is
> > made (it's common to have branch for this kind of tasks, but branches
> > sux on svn).
> >
>
> Is there a way for us to solve this using the available structure
> provided by google code? Is there another alternative that don't suck
> (e.g. sourceforge)?
What sux (IMO, no flames please) is SVN branch support, but I don't
want to advocate a change to git at this point... I think we should
live with that for now (and thus you should make a commit changing the
release-version, create a tag, create the tarballs with "make dist"
and then return the version on trunk to a X.xsvn - or whatever you
choose).
>
> > Traditionally, svn snapshots include the date (YYYYMMDD) or the svn
> > revision in the tarball. Official releases should have a proper
> > release-notes (news on the website, e-mail on the devel list, etc) and
> > a tag on SVN.
>
> It was not intended to be a snapshot (so, no need to add the date in
> tarball name). Not only that, but I think it doesn't make sense
> provide svn snapshots because:
>
> a) The svn version must be *always* compilable (and whoever breaks the
> code will need to pay some snacks to the team...)
> b) The user that wants to live in the 'edge', can just checkout the
> code from repository
I agree 100% with that. It would make sense to release snapshot-builds
*if* the code was big and we had lots of testers, which is clearly not
the case.
>
> Concerning the items that you had written, let's see the list:
> - news on website ........ ok
> - email on devel-list ..... no (but we have only 4 active developers,
> do we need an email in devel list?
> If I recall correctly, I had contacted each developer individually to
> announce the plan to release amora within few days)
> - email on user-list ....... ok
> - svn tag ....................... ok
I think it's good to send things to the list because it gets recorded
on the list archives and thus it's useful for "future generations" and
for whoever googles for amora. As for the rest, you did an excelent
work announcing amora. :-)
<snip>
> > It's up to the user to decide that, not the developer. If you find a
> > bug, you fix it and release a new version, but it's always nice to let
> > at least two versions available for download, so that the users may
> > run tests and notify you of regressions.
> >
>
> Yes, indeed. But I think is not sensible keep a previous bugged
> release 'featured' just for the sake of making it available (i.e. the
> bugged amora client SIS is *still* available for download, but is not
> featured in the project's website. What I had done was to release a
> 1.0-1 version with packaging fixed).
Yes, specially in cases of minor bugfixes (maintainance releases),
it's OK to have just the latest version, but I think the major reason
for my whining was that I didn't know google-code was keeping the old
files available... Blame the non-intuitive interface :-P
>
> When it makes sense, yes it can be done (e.g. when I released amora
> 0.8, I kept client version 0.7 for older cellphones 'featured' since I
> had not have time to test it properly in S60 2ed devices).
OK, I think we can all agree that the "featured" download should
include only the latest versions and the old ones should be marked as
"deprecated".
>
> Contrast that with Amora 1.0, which had being well tested in both S60
> 3ed and 2ed devices.
Famous last words :-P
<snip>
> >
> > I'm OK with the roadmap, my concern is because users may get amora
> > directly from distributions or other sources, thus a proper ChangeLog
> > (and a consistent release version) are important (actually, I found
> > these problems while adding the 1.0 version to the official mandriva
> > repositories).
> >
>
> Could you elaborate more on the 'problems' part? Assuming that we will
> bundle a changelog with the tarball and remove the nefarious 'svn'
> suffix in the package name (and the site project already hosts older
> version releases), what else is missing?
By "problems" I mean the inconsistency in the version (the svn sufix
which I believed was from a svn snapshot) and the lack of the previous
versions on the download page. All solved by now. :-)
So, all in all, thanks for the great work so far and for clarifying
some points. :-)