tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Proposed release outline


From: grischka
Subject: Re: [Tinycc-devel] Proposed release outline
Date: Fri, 07 Dec 2012 17:09:52 +0100
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

Thomas Preud'homme wrote:
Le jeudi 6 décembre 2012 17:00:40, grischka a écrit :
Well, release would be fine for me.  Honestly, even better if someone else
could do it.  Steps IIRC are:

- update Changelog and VERSION
- tag the git revision
- pack archives and upload to savannah
   (http://download.savannah.gnu.org/releases/tinycc/)

What do you mean by pack? Do you mean binary archives? If you mean source archive, can't the archive of master from git.or.cz be used for source archive once we decide master is ready?

Yes, source tree, except that we used to include a compiled tcc-doc.html.

There is also the 'tar' make target but it might be somewhat out of date
wrt. excludes.


- inform Fabrice (including the one-liner release description for his web
page)

Thomas? ;)

Ok, I should be able to do that without errors.

Basically since you (and others) did most of the work recently you have
better overview what has be done and if/when it is ready for release.
Generally my impression is that tinycc is still in reasonable shape overall
(i.e. works and is fast and small).

I'm not so sure about the overview but I'll try a cooperative approach whose outline is the following:

1) Announce a release candidate release. If possible make a tarball available somewhere or maybe add a tag in git. At least announce it

If you want a candidate, then, well ...


2) Start to only include in master cherry-pick of bugfix in mob. Also kindly ask people to consider only commiting in mob bugfixes (but let mob widely open).

I'd also not bother with cherry-picking.  I did that in the past but the
problem is that it is much work and also looses history.  I'd suggest to
take the tip of mob, and if some revision looks bad, revert it.


3) Ask people to check their contributions is mentionned in the Changelog

I'd also not add too much to the Changelog.  Just mention the major themes
that were approached since last release.  Basically what is visible to the
user, such as new switches, new features.  20-30 lines.  You don't need
to keep everything from what there is currently.


[LATER]

4) Ask if anybody still has plan to fix things

[LATER]

5) Release according to the steps you gave.

I'm very busy and will continue to do so for the next 16 days. I'll try to start steps 1-3 in the next couple of days though. Then I'll be able to answer again and will continue with steps 4 and 5.


Thanks,

--- grischka


Also I don't have a working linux installation right now.  I can contribute
the windows binary pack though if needed.

Good, because I have linux but no Windows. :) We'll complement each other.

--- grischka

Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]