|
|
Line 591: |
Line 591: |
| ===When to recompile/build=== | | ===When to recompile/build=== |
|
| |
|
| Edward wrote:
| | Watch for release announcements [1] or subscribe to the flightgear-commitlogs mailing list [2] (lots of emails). |
| <blockquote>
| | |
| There are a number of ways to follow this:
| |
| | |
| - Watch for release announcements [1]. These announcements
| |
| correspond to the git tags for the releases, not the git release
| |
| branches.
| |
| | |
| - Subscribe to the flightgear-commitlogs mailing list [2]. You
| |
| will receive one email per commit on all the FG repositories, so it is
| |
| a little noisy, but you'll see when releases are branched and when
| |
| they are tagged.
| |
| | |
| - Follow this list (note: Flightgear-devel@lists.sourceforge.net) for messages from James as to when he creates a
| |
| new release branch. This will be the initial branch that commits are
| |
| cherry-picked to, and tags made for different release revision
| |
| numbers.
| |
| | |
| - Go completely nerdy and write a very complex cron job script to
| |
| email you when specific remote repository events occur (not
| |
| recommended, as email filtering of the flightgear-commitlogs messages
| |
| is easier). This is risky because if you accidentally poll SF too
| |
| quickly, they will permanently IP blacklist you.
| |
| | |
| If you are interested in development, you absolutely should be making
| |
| changes based on the 'next' branch. You should also develop by
| |
| committing changes to branches on your local repository - not by using
| |
| stashing or git-worktree. You can use 'git rebase -i next' (after
| |
| merging 'origin/next' to your local 'next') to pick up your branch
| |
| point and shift it to the latest code. Or just delete the branch with
| |
| 'git branch -D [branch_name]'. Don't be afraid to have lots of
| |
| local-only branches. It is a good way, and the correct VCS (version
| |
| control systems) way, to organise your coding. I have 30 untracked
| |
| branches for my flightgear clone, 19 for simgear, and 2 for fgdata. I
| |
| highly recommend not touching git-worktree, as that is not how
| |
| developers normally use git! This tool has a specific purpose - for
| |
| example fast switching to maintain, build, and release new revisions
| |
| for ancient long-term releases - but this purpose is not what
| |
| developers use for normal development. And with the CMake build
| |
| system git-worktree is partly redundant as you just create different
| |
| 'build' directories for the different releases.
| |
| | |
| Anyway, for normal VCS development just use lots of local repository
| |
| branches. You can then push interesting ones you would like backed up
| |
| to your remote fork.
| |
| | |
| Regards,
| |
| Edward
| |
|
| |
|
| [1] https://www.flightgear.org/category/news/ | | [1] https://www.flightgear.org/category/news/ |
|
| |
|
| [2] https://sourceforge.net/projects/flightgear/lists/flightgear-commitlogs | | [2] https://sourceforge.net/projects/flightgear/lists/flightgear-commitlogs |
|
| |
| </blockquote>
| |
|
| |
|
| ===Download_and_compile.sh=== | | ===Download_and_compile.sh=== |