Development Model - Revision history

Nozmajner: updating

2017-09-02T21:47:27Z

updating

Nozmajner at 21:40, 2 September 2017

2017-09-02T21:40:31Z

Nozmajner: Removing the mailng list, adding forum and PR

2017-09-02T21:38:50Z

Removing the mailng list, adding forum and PR

Jmf at 00:19, 18 August 2013

2013-08-18T00:19:22Z

RobN: moved Our Development Model to Development Model

2012-09-08T03:54:31Z

moved Our Development Model to Development Model

Philbywhizz: tweak release table look

2012-09-07T07:26:43Z

tweak release table look

Philbywhizz: Import of development model

2012-09-07T00:33:01Z

Import of development model

New page

Pioneer's primary repository is hosted at https://github.com/pioneerspacesim/pioneer. To do any hacking you need your own clone of the repository. We recommend that you host your own repository on Github by forking the primary repository as we make heavy use of Github's features, but in the finest git tradition you're welcome to manage your copy of the code as you please.

=Getting your changes into Pioneer=

==Create feature branch==
Get your master copy up to date with the central repository, and create a branch for whatever it is that you're working on.

==Implement feature==
Hack hack hack! This is the fun bit! Its recommended you stay in close contact with the other developers, either via IRC or the mailing list, to make sure that your work fits with the rest of the project.

==Request merge==
Once your code is ready you need to request that it be merged. If you're using Github, the standard mechanism is a pull request. This creates an issue in the issue tracker so your request doesn't get lost. If you're not using Github you should manually create an issue, point to a place where your repository can be accessed and the SHA1 of the branch head you want merged. We prefer the SHA1 over the symbolic ref so we can be sure that we're reviewing the same code.

==Review==
Once you've requested a merge someone will review your code. This is the most important part of the process. We insist on a review for two reasons:

* Ensuring that the codebase remains consistent and there are no glaringly obvious bugs or structural defects in your code
* Giving the reviewer an opportunity to learn your code and the parts of the codebase you changed
For small changes the review will often be a quick nod from someone in IRC, possibly even the merge manager doing the review at the same time as the merge. Larger changes will require a more thorough review, possibly by more than one person (if an expert in a particular area is required).

When the review is completed the reviewer should make a note on the relevant issue to indicate the branch is ready for merge.

If the change does not pass review then the reviewer should note the problems in the issue. You should go back and fix the things that the reviewer flagged as problems and then update the issue/pull request with the new SHA1. The original reviewer should take the lead on follow-up reviews to make sure that all the original problems are addressed.

==Merge==

Once the review is complete the merge manager will complete the merge and push an updated master. Congratulations, your code is now a part of Pioneer!

=Release process=
From alpha 11 onwards Pioneer works on a timeboxed release schedule. Releases occur on the second Friday of each month. A release branch is created one week before this release. No new development is accepted onto this branch - only critical bugfixes and documentation updates.

{| class="wikitable"
|+Projected release dates
|-
!Release
!Freeze date
!Release date
|-
|Alpha 14
|2 September
|9 September
|-
|Alpha 15
|7 October
|14 October
|-
|Alpha 16
|4 November
|11 November
|-
|Alpha 17
|2 December
|9 December
|-
|Alpha 18
|6 January
|13 January
|}

''need to update this table'' [[User:Philbywhizz|Philbywhizz]] 17:33, 6 September 2012 (PDT)

==Freeze==
On the freeze date the release manager will create a new branch for the release. Development can continue according to the normal development process and code will be merged to master as normal. No new features will be included on the release branch except for critical bugfixes (as determined by the development team).

The main purpose of the release branch is to give us time to test, update docs and prepare for release.

==Release==
Things that need to be done for release:

* Ensure the Changelog, AUTHORS, README and other docs are up to date.
* Do the builds
* Test the builds. This includes making sure they run and making sure all the necessary files are included.
* Upload
* Update the download page with links, MD5 sums and the change log
* Post announcements to:
** pioneerspacesim.net news page
** spacesimcentral.com forum
** moddb.com page

@@ Line 32: / Line 32: @@
 Once the review is complete the merge manager will complete the merge and push an updated master. Congratulations, your code is now a part of Pioneer!
 =Release process=
 Once pioneer was released as alphas with freezing period. This changed after alpha33.
-Twice a day a complete build for Windows and Linux will be run and uploaded (though obviously not if no changes have been made).
+If there are changes that warrant it, new things, fixes, then&nbsp;a complete build for Windows and Linux will be run and uploaded (though obviously not if no changes have been made). Version numbers are formatted like YYYYMMDD. So a build for today might be 20170827. The latest build will always be linked from pioneerspacesim.net, and the last week's worth of builds will be archived, just in case. Geraldine also archives a windows build once a month on moddb.
-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.
+To keep the changes visible, the changelog for the last month is visible on the main page,&nbsp;the G+, Twitter. The full changelog can be found on github.
 Of course, the current changelog will always be available from the homepage and in the release archives proper.
@@ Line 46: / Line 45: @@
 This should mean that if you encounter a bug, the fix is available to you in an official, supported build as soon as possible.
-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..
+== Release ==
 Things that need to be done for release:
-* Ensure the Changelog, AUTHORS, README and other docs are up to date.
+*Ensure the Changelog, AUTHORS, README and other docs are up to date.
-* Do the builds
+*Do the builds
-* Test the builds. This includes making sure they run and making sure all the necessary files are included.
+*Test the builds. This includes making sure they run and making sure all the necessary files are included.
-* Upload
+*Upload
-* Update the download page with links, MD5 sums and the change log
+*Update the download page with links, MD5 sums and the change log
-* Post announcements to:
+*Post announcements to:
-** pioneerspacesim.net news page
+**pioneerspacesim.net news page (automatic)
-** google+
+**google+
-** spacesimcentral.com forum
+**spacesimcentral.com forum
-** moddb.com page
+**moddb.com page

@@ Line 14: / Line 14: @@
 Once your code is ready you need to request that it be merged. If you're using Github, the standard mechanism is a pull request. This creates an issue in the issue tracker so your request doesn't get lost. If you're not using Github you should manually create an issue, point to a place where your repository can be accessed and the SHA1 of the branch head you want merged. We prefer the SHA1 over the symbolic ref so we can be sure that we're reviewing the same code.
-* Ensuring that the codebase remains consistent and there are no glaringly obvious bugs or structural defects in your code
+== Review ==
 * Giving the reviewer an opportunity to learn your code and the parts of the codebase you changed
 For small changes the review will often be a quick nod from someone in IRC, possibly even the merge manager doing the review at the same time as the merge. Larger changes will require a more thorough review, possibly by more than one person (if an expert in a particular area is required).

@@ Line 6: / Line 6: @@
 Get your master copy up to date with the central repository, and create a branch for whatever it is that you're working on.
 ==Implement feature==
-Hack hack hack! This is the fun bit! Its recommended you stay in close contact with the other developers, either via IRC or the mailing list, to make sure that your work fits with the rest of the project.
+== Implement feature ==
 ==Request merge==

← Older revision	Revision as of 03:54, 8 September 2012
(No difference)

@@ Line 38: / Line 38: @@
 |-
 |Alpha 14
-|2 September
+|2 September 2011
-|9 September
+|9 September 2011
 |-
 |Alpha 15
-|7 October
+|7 October 2011
-|14 October
+|14 October 2011
 |-
 |Alpha 16
-|4 November
+|4 November 2011
-|11 November
+|11 November 2011
 |-
 |Alpha 17
-|2 December
+|2 December 2011
-|9 December
+|9 December 2011
 |-
 |Alpha 18
-|6 January
+|6 January 2012
-|13 January
+|13 January 2012
 |}