Notifications
Clear all

Changes to the release process


robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
Topic starter  

As you know, for a couple of years now Pioneer has had an alpha release on the second Friday of every month without fail. The dev team has always considered this to be an immovable deadline, and it has been useful in giving us something to aim for. To try and help make sure the alpha releases are sort-of stable, we've also had a "freeze" period a week before the release, to allow testing and last-minute fixes to happen, ensuring a stable release.

Lately its become clear that that model isn't giving the best results. Very few people actually do freeze testing, so we don't usually find any problems, yet real actual bugs are often missed, leading to the situation we've had a couple of times recently where the alpha has a nasty bug. Its usually fixed hours later, but that fix doesn't make a release until the next alpha a month later. Meanwhile, new development continues to happen on the master branch during the freeze week so that by the time the alpha is released it's already obsolete.

All of this means the alpha releases are becoming more of a burden than a useful part of the process, so we've made the decision to drop it. Obviously though we need to get something out into the hands of players and testers, so we're intending to promote the nightly builds to "official" status as follows. Twice a day a complete build for Windows and Linux will be run and uploaded (though obviously not if no changes have been made). Version numbers will be changed to YYMM.BB, where BB is the "build number" for that month. So a build for today might be 1305.2. The latest build will always be linked from pioneerspacesim.net, and the last week's worth of builds will be archived, just in case.

To keep the changes visible, we'll be making a "what's new in Pioneer" post to this forum, the G+ page and a few other places at the start of each month with the changelog for the previous month. Of course, the current changelog will always be available from the homepage and in the release archives proper.

This should mean that if you encounter a bug, the fix is available to you in an official, supported build as soon as possible. Of course, there's also challenges involved with this. It will mean that we need to be more careful about ensuring that broken code doesn't make it to the master branch, and we can't be as blasé about breaking savefile compatibility as we have been in the past. That's good though; it puts pressure on us to work towards things that we've been wanting to do for a while now, like a new save system that better supports upgrading old savefiles and stabilising the procedural generation so that minor code changes don't break the entire galaxy.

Right now OS X builds won't have the same twice-daily build schedule, as they're currently compiled semi-automatically by Philbywhizz when he has time. We're working on getting these happening as soon as we can, which might mean changes to this process, not sure yet. We'll let you know the outcome of that. The homepage will list the most recent build available for OS X.

We're aware that asking people to regularly download a 150-200MB archive is a bit of a stretch, so we're also looking at ways to reduce the amount of stuff you need to grab to get a new build. That might be splitting the game data from the binaries, it might be a patch system, it might be something else. Again, we'll let you know.

This change is effective immediately (as soon as I've made the necessary changes to the build system to support it). So there won't be an alpha 34. The first builds under this scheme should be available in the next few days.

Thanks as always for your support. Feedback welcome 🙂


Quote
Geraldine
(@geraldine)
Rear Admiral Registered
Joined: 7 years ago
Posts: 3446
 

Hi Robn

Is it ok if I post your announcement on ModDB? Or would it be best to wait until it's been decided on how the updates will work?


ReplyQuote
Starblade
(@starblade)
Crewman Registered
Joined: 11 years ago
Posts: 9
 

We can still get the files from http://sourceforge.net/projects/pioneerspacesim/files/nightly/

 

Or better release the alphas every 2 weeks. This means those bugs will never be around that much time, but still give us time to proper play . 

 

As someone who has done Total Conversions and some quick games my advise is move the project to a closed state (no more changes in the flight model, or docking procedures or the auto pilot, etc). Move into factions and combat, otherwise you still be coding this until you need Viagra to get it up...


ReplyQuote
DarkOne
(@sscadmin)
Supreme Dark Emperor Admin
Joined: 8 years ago
Posts: 7856
 

Personally I would make releases more spread out, maybe once every month or two. Because people do have access to build/compile pioneer if they want the latest and that would be the way to solve the issues of people wanting frequent updates. I almost look at your release schedule as counter-productive. I mean this is a open-source project and not something that is using agile/scrumm process so having short release cycles really doesn't benefit the developers or the consumers. 


ReplyQuote
robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
Topic starter  

Is it ok if I post your announcement on ModDB? Or would it be best to wait until it's been decided on how the updates will work?

You should post now. It will all just be regular downloads for now.


ReplyQuote
robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
Topic starter  

We can still get the files from http://sourceforge.net/projects/pioneerspacesim/files/nightly/

For now. That'll all be cleared once I have the new stuff set up. There won't be separate nightly builds anymore.
 

Or better release the alphas every 2 weeks. This means those bugs will never be around that much time, but still give us time to proper play .

That just adds additional overhead. Preparing and releasing an alpha takes time.

As someone who has done Total Conversions and some quick games my advise is move the project to a closed state (no more changes in the flight model, or docking procedures or the auto pilot, etc). Move into factions and combat, otherwise you still be coding this until you need Viagra to get it up...

Except that some things need changes. There's a lot of code that needs rewriting still. I don't think you appreciate just how nasty and horrible and wrong some of Pioneer's internals are 🙂


ReplyQuote
robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
Topic starter  

Personally I would make releases more spread out, maybe once every month or two.

The problem is testing. The resources to adequately test before release don't appear to be available, despite our efforts to make it happen. So we invariably make a release that is almost immediately useless.

Because people do have access to build/compile pioneer if they want the latest and that would be the way to solve the issues of people wanting frequent updates.

Very few people actually compile Pioneer. Our players appear to be more of the gamer types than the open-source types. They want to download something and play it, not muck around with compilers and whatever else. That's something I'm ok with - it is a game, after all. But saying "grab the code and build it yourself" to get a critical bugfix is not at all helpful.

I almost look at your release schedule as counter-productive. I mean this is a open-source project and not something that is using agile/scrumm process so having short release cycles really doesn't benefit the developers or the consumers.

We actually operate in a very agile way - fast, iterative development and constant deployment. Automatic releases of the kind we're switching to benefit the developers because we aren't left supporting older versions with bugs that we've already fixed and don't require the not-insigificant overhead of preparing a monthly release. It benefits the players because they get a constant stream of updates and fixes without having to wait a month.

Of course this process is for while we're in rapid development. Later, once we're more stable, we might go back to something like the old process.


ReplyQuote
Geraldine
(@geraldine)
Rear Admiral Registered
Joined: 7 years ago
Posts: 3446
 

You should post now. It will all just be regular downloads for now.

 

ModDB updated with the news Robn.


ReplyQuote
Zordey
(@zordey)
Senior Chief Registered
Joined: 12 years ago
Posts: 75
 

I think this is a good move from a development point of view. Working to very strict deadlines causes code to be rushed in the last few days to get it in before the freeze so that it is not another month before it is included.

 

I download the nightlys from git and compile myself and any issues get fixed quickly but I can see how this would not be for everyone.

 

Some sort of core download and auto patch system for end users would be nice, but at this stage of development I dont know if that would be practical.


ReplyQuote
 Anonymous
Joined: 54 years ago
Posts: 0
 

There will be the new releases available in the twitter page?


ReplyQuote
 Anonymous
Joined: 54 years ago
Posts: 0
 

There will be the new releases available in the twitter page?

 

It should, but I think the build script might need fixing to make this work again.

 

As always, the builds can be downloaded from http://sourceforge.net/projects/pioneerspacesim/files/

 

John B


ReplyQuote
robn
 robn
(@robn)
Captain Registered
Joined: 13 years ago
Posts: 1035
Topic starter  

Fyi, I just finished updating the website, so it now shows the latest build and changelog updates (regenerated every half hour).

So we're almost there. Most of the rest is internal stuff.

I'll post April's changelog update in a minute.


ReplyQuote