Guten Tag Joseph Southwell, am Freitag, 3. Januar 2014 um 15:49 schrieben Sie:
> Perhaps I am behind the times, but that doesn't match my > expectation when I go check out a source repository for a project. > If I want to try the bleeding edge of development code I always go > checkout trunk. Having that not be the bleeding edge seems like > another thing we would have to document and tell people about. There are quite some projects defining trunk as something more stable than "bleeding edge", feature and committer specific branches are never recognized in a trunk, too. But the main point is: What gets automatically published as https://logging.apache.org/log4cxx/ ? If I look at https://logging.apache.org/log4cxx/changes-report.html, version 0.11.0 is mentioned with a release date of "2010-XX-XX" and a description, but this version got never released and is not downloadable. It is only mentioned because it's in trunk and development takes place in trunk. The header of the website tells about "Version: 0.11.0-SNAPSHOT", too, is the current official release of the project and one shouldn't not download what is available under download, but should use this version instead? I find this confusing, from my point of view a project should publish what should publicly be used, other projects describe internal development versions and branches as such and don't just publish them because they are in trunk. You would need to document how your project acts with branches etc. in any case. If trunk gets automatically published and only contains what a project sees as official release, there won't be any doubt what a user uses. Currently one has to decide if one downloads 0.10.0 from the download page or uses 0.11.0 because it's last mentioned on the changes page or maybe even searches for 0.11.0-SNAPSHOT because it's mentioned in the header. If it was my project I would have created a tag which would get automatically published somewhere and would only contain the last stable release I would want people to use. I really don't care if it's called "tags/stable" or "trunk" or whatever, but what I think we should publish is only stable releases and not a branch or trunk or whatever were common development takes place. If one wants to have access to bleeding edge code, one will in any case access and look through the whole repository. > I applaud the order you are attempting to add to the situation with > those future version branches but I am not sure the management > overhead makes sense with such a small team. We would only have some overhead for the first releases, 0.11.0 and 0.11.1 would get merged back to trunk during their release and deleted as branches, only keeping the "active development branches" we would want, 0.12.0 in the beginning. But I can live with working in and publishing trunk. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
