Talk:Trunk (software)
 | This redirect does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
| |||||||||||
 | The contents of the Trunk (software) page were merged into Branching (version control) on 3 April 2022 and it now redirects there. For the contribution history and old versions of the merged article please see its history. |
Definition
[edit]main version? the most stable code? There is truth to these statements but it distracts from the main point, the version of a software product under active development. Foolswisdom 20:45, 2 January 2007 (UTC)
- What do you mean by active development? Surely branches are under development, as well? --Eyrian 20:50, 2 January 2007 (UTC)
- All branches are under active development. Therefore, calling the trunk 'main version' or 'most/least stable code (depending on policy)' is correct. -- 220.226.73.168 13:01, 1 September 2007 (UTC)
Could it be something like "official version"? Like the Linux Kernel, thers a lot of versions, but just one is the official one, does it have sense?
Origin
[edit]Where did the "trunk" term come from ? —Preceding unsigned comment added by 80.72.35.146 (talk) 10:49, 23 December 2009 (UTC)
Best Practice on Fix Bugs and Merges and which policy helps with it best
[edit]i have ran into several arguments about feature branches and bugfixing "directions". And i assume there are several more opinions for debates about the nature of trunk branching policy.
- feature branches
people try to use feature branches because they think this way they can easily switch on and off features
- however this isn't true feature branches can conflict in such ways that a merge of both might even require a third time (re)writing of the code. this is especially true when design principles are "ignored"
- in practice the one in charge of the merge is neither of those that have originally implemented the features so a third time understanding the code is required as well
- if all features are developed in the trunk updates during development show problems directly to the developer in charge of the feature and giving the chance to cleanly rewrite the code correctly
- use of feature branches also discourages the practice of refactoring (updating the quality of existing code without changing it's functionality). Due to merge complexities such broad scale changes are avoided. This results in a stagnating code base. — Preceding unsigned comment added by 24.141.57.211 (talk) 22:36, 10 October 2018 (UTC)
- bugfixing backwards
fixing bugs in a past version and merging it into a new one is uncritical at best or if the project has changed greatly the fix isn't required or has to be written newly.
- doing a fix in a new version can lead fixes that cant be ported back into the previous versions because dependencies might not exists in that version
- also some code of new "features" might leak into the old version if the merge isn't done carefully
due to these facts i assume its best practice to
- develop in the trunk
- have version branches
- fix bugs in the first version the bug was introduced
objections?! —Preceding unsigned comment added by 79.247.188.54 (talk) 01:46, 30 September 2010 (UTC)
Synonyms
[edit]Are mainline and main branch both synonyms for trunk? --Abdull (talk) 10:26, 3 October 2010 (UTC)
Delete this page!
[edit]The term trunk comes from the version control system Subversion. It is only used there and nowhere else. So please delete this page or make it VERY clear where the term comes from! -- 217.71.245.65 (talk) 12:29, 15 May 2013 (UTC)