Would the future also contain the MP protocol+player enviroment, ATC, MP
mapping ?
a monthly release would be nice with hot fixes..
and also all the aircraft independant in hangars
and is fgrun included
pete
On Tue, Jun 15, 2010 at 9:58 PM, Durk Talsma <[email protected]> wrote:
> Hi James,
>
> On Friday 07 May 2010 06:06:32 pm James Turner wrote:
>
> > Anyway, the key thing - what are the steps to make a release happen. I'm
>
> > seeking to capture the actual steps (and ideally script them), so even if
>
> > Curt & Durk both get hit by the proverbial bus tomorrow, we can still
> make
>
> > a Flightgear release ever again. But also, I'm seeking to remove the
> human
>
> > factors from the release process, and especially not feel that we're
>
> > overloading people just because a release needs to happen - eg, around
>
> > LinuxTag Durk is often quite busy organising things :)
>
> >
>
> Well, I already gave you the outline over breakfast in Berlin, but
> nevertheless, I feel that it doesn't hurt to give a quick summary of our
> generic release procedure. I'll start by our historical cvs based procedure,
> and will later on give some indication as to how we can fit in our new git
> repository.
>
> When I first started coordinating the releases, my first and foremost aim
> was to regularize the release cycle by making sure we did at least one
> release a year. More or less coincidentally, this happened around Christmas
> / end of the year. Typically preparations for the release started sometime
> in September / October by sending out a couple of emails to the developers
> list. These emails concerned matters such as our base package aircraft
> selection and the request to set a date for a feature freeze. Typically,
> October through late November were filled with bug fixing. Once we
> determined that the could was reasonably stable, I would update the version
> numbers for simgear, flightgear, and data, and run a make dist command on
> all three. Then, I would tag the CVS repositories and place the tar files
> resulting from the make dist commands somewhere on an ftp / web server.
> Usually this was my home PC, which was connected to the Internet through a
> rather slow wireless lan and ADSL upload link. I'd announce the presence of
> these packages to Curt, Fred, and Tatsuhiro, who would make the sources
> available for public download and build the windows and mac binary
> distributions respectively. Eventually, all files would be sent to Curt for
> placement on the flightgear.org website. This procedure would start with
> one release candidate and repeated if necessary.
>
> While we were approaching the final stages of the release cycle, I would
> start browsing the commit logs, in order to write a comprehensive summary of
> all the major changes that had happened during that year. In more recent
> years, this also included generating some screen shots for promotional
> purposes and writing a release announcement.
>
> Starting with the maintenance release 1.9.1, we began using Tim Moore's git
> repository. The obvious advantage was that Tim was able to only push bug
> fixes from CVS into the git repository, so that development of new features
> could continue without the risk of breaking the stable code base.
>
> FlightGear 2.0 was entirely -as in source code- released from git, while
> the data tree was still downloaded from CVS. For this release, we changed
> our policy slightly, because we weren't too thrilled about having to push a
> 250+ MB base package through my slow ADSL upload. So, instead, we tagged the
> base package and asked Curt, Fred, and Tatsuhiro, to check and build the
> base package themselves.
>
> The release process of FlightGear 2.0 clearly marked a transition. Although
> the procedure worked reasonably well, we did encounter a few glitches. The
> most striking one was that it was seemingly impossible for me to remotely
> tag the base package, so I had to request that Curt finishes this job. In
> the midst of this, I wasn't able to build FlightGear on a clean system, so I
> missed the fact that a few files were not included in the data tar file, as
> well as running into a few other miscellaneous problems.
>
> With git allowing much finer grained control over revision changes, I don't
> think that we should encounter such trouble in the near future. With your
> automatic build system in place, we should in fact be able to automatize
> much of the process. The only two things that I can think of are 1) the fact
> that non-technical side of the release process (writing a ChangeLog summary;
> generating promotional materials) as well as pushing the result onto a
> central ftp server still requires some manual intervention. The question is
> how we could streamline that.
>
> Cheers,
>
> Durk
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
