AFAIK, there's no conclusion, besides from "we need something to "tag" stable things in our SVN".
Here's an example to better explain what Tekkub means (if I understood correctly):
/trunk is used for active devs.
/stable is used to store stable versions.
When someone creates a new addon, namely Foo, it will create /trunk/Foo. If Foo used LibBar, it would have an externals pointing to /stable/LibBar. Once Foo reachs a first stable point, it is tagged to /stable/Foo. Subsequent stable versions will be merged into that /stable/Foo.
Now, how with the libraries ?
When a new library is created, namely LibZee, it lives in /trunk/LibZee. Once it reachs the first stable point, it is tagged into /stable/LibZee. Subsequent stable versions will be merged into /stable/LibZee.
Now compares this proposal with a fully tagged system :
/trunk is used for active devs,
/tag is used to store stable versions.
When someone creates a new addon, namely Foo, it will create /trunk/Foo. If Foo used LibBar, it would have an externals pointing to, say, /tag/LibBar/stable/1.0. Once Foo reachs a first stable point, it is tagged to /tag/Foo/stable/1.0. Subsequent stable versions will create new tags /tag/Foo/stable/1.1, /tag/Foo/stable/1.2, ...
Now, how with the libraries ?
When a new library is created, namely LibZee, it lives in /trunk/LibZee. Once it reachs the first stable point, it is tagged into /tag/LibZee/stable/1.0. Subsequent stable versions will create new tags: /tag/LibZee/stable/1.1, /tag/LibZee/stable/1.2, ... We should NEVER commit to existing tag, even for small bugfixes. It means that if LibZee-1.0 should be integrate bugfixes, it will lead to a new tag, not a LibZee-1.0-with-higher-revision. And every addon that are using LibZee-1.0 should updated to use the bugfixed version. Moreover, several versions of that lib will live in memory...
Aye, tags is a great tool in normal production where the end user installs a specific version and runs with it, potentially never updating it (Who knows someone running Win95 still?)... but our SVN is far from normal.
I thing something along the lines of a "stable" path is definitely the route to go. Don't make it like tags or branches where there's potential for duplicates, that'll cause more trouble than good. Making it similar to trunk, where there is only one instance of any give addon or library major version, is a good thing.
Guess we need to get kael to look at this so he can plan repos around some sort of design like this :)
personally we still need a /tags dir that is sealed once you commit ... because tbh the mainstream addons are very very stable.. ie bigwigs/ora2/bartender and generally only need to be touched in any life threatening way once every major wow-patch (read 1.12) and the /tags could be for the main distro addon sites like curse / ui / wow interface. then again the authors could just once every few months post a stable to it them selfs, so it's not a need but a convince
personally we still need a /tags dir that is sealed once you commit ... because tbh the mainstream addons are very very stable.. ie bigwigs/ora2/bartender and generally only need to be touched in any life threatening way once every major wow-patch (read 1.12) and the /tags could be for the main distro addon sites like curse / ui / wow interface. then again the authors could just once every few months post a stable to it them selfs, so it's not a need but a convince
Here's an example to better explain what Tekkub means (if I understood correctly):
/trunk is used for active devs.
/stable is used to store stable versions.
When someone creates a new addon, namely Foo, it will create /trunk/Foo. If Foo used LibBar, it would have an externals pointing to /stable/LibBar. Once Foo reachs a first stable point, it is tagged to /stable/Foo. Subsequent stable versions will be merged into that /stable/Foo.
Now, how with the libraries ?
When a new library is created, namely LibZee, it lives in /trunk/LibZee. Once it reachs the first stable point, it is tagged into /stable/LibZee. Subsequent stable versions will be merged into /stable/LibZee.
Now compares this proposal with a fully tagged system :
/trunk is used for active devs,
/tag is used to store stable versions.
When someone creates a new addon, namely Foo, it will create /trunk/Foo. If Foo used LibBar, it would have an externals pointing to, say, /tag/LibBar/stable/1.0. Once Foo reachs a first stable point, it is tagged to /tag/Foo/stable/1.0. Subsequent stable versions will create new tags /tag/Foo/stable/1.1, /tag/Foo/stable/1.2, ...
Now, how with the libraries ?
When a new library is created, namely LibZee, it lives in /trunk/LibZee. Once it reachs the first stable point, it is tagged into /tag/LibZee/stable/1.0. Subsequent stable versions will create new tags: /tag/LibZee/stable/1.1, /tag/LibZee/stable/1.2, ... We should NEVER commit to existing tag, even for small bugfixes. It means that if LibZee-1.0 should be integrate bugfixes, it will lead to a new tag, not a LibZee-1.0-with-higher-revision. And every addon that are using LibZee-1.0 should updated to use the bugfixed version. Moreover, several versions of that lib will live in memory...
So, I vote for Tekkub's proposal.
I thing something along the lines of a "stable" path is definitely the route to go. Don't make it like tags or branches where there's potential for duplicates, that'll cause more trouble than good. Making it similar to trunk, where there is only one instance of any give addon or library major version, is a good thing.
Guess we need to get kael to look at this so he can plan repos around some sort of design like this :)
personally we still need a /tags dir that is sealed once you commit ... because tbh the mainstream addons are very very stable.. ie bigwigs/ora2/bartender and generally only need to be touched in any life threatening way once every major wow-patch (read 1.12) and the /tags could be for the main distro addon sites like curse / ui / wow interface. then again the authors could just once every few months post a stable to it them selfs, so it's not a need but a convince
Agreed.
/waits for an SVN administrator to appear