Our records show that you have outstanding author rewards points. Please confirm your latest payment information and redeem your points balance via the Author Reward Store.
I think much of the drama of the last few days could have been eliminated had there been seperate beta and release repositories. When the WAU first came online it was nice for many dev's of addons and beta testers wanting to be on the bleeding edge. However, many guilds now require Threat-1.0 - it is updated often so we need to run WAU often. WAU is mainstream and very popular. It is common for peeps to run WAU, login to run raids or group activities that require those precious addons that we have come to love. Sudden global changes effect our game play and could effect our ability to raid, PVP or whatever.
Duel repositories would eliminate dramatic changes and dramatic reactions.
I propose that every developer makes stable releases, and that users use these releases instead of testing (wich is to be used for testing).
Multiple repositories are not needed for this. Instead, if WAU would use /tags instead of /trunk, people will enjoy less updates (good) and tested addons, provided that developers test their addons before release.
There is no need for dual repos. The root level of the repo has three folders: trunk, branches and tags. Trunk is the "main" development, so it's generally alpha to working-beta quality. Branches is for working seperate from trunk, you might want to call it alpha. Changes in branch are generally merged to trunk once they're tested and complete. Tags is for "saving" specific snapshot, I.E. numbered versions. Some specific naming scheme would have to be applied to tags so WAU knew if it was a beta or a full release, but the whole repo IS designed around the whole version numbers thing, it is a Version Control System after all.
There is no need for dual repos. The root level of the repo has three folders: trunk, branches and tags. Trunk is the "main" development, so it's generally alpha to working-beta quality. Branches is for working seperate from trunk, you might want to call it alpha. Changes in branch are generally merged to trunk once they're tested and complete. Tags is for "saving" specific snapshot, I.E. numbered versions. Some specific naming scheme would have to be applied to tags so WAU knew if it was a beta or a full release, but the whole repo IS designed around the whole version numbers thing, it is a Version Control System after all.
Theoretically I agree - but it doesn't really seem like anyone asked the guys behind the updater apps to use /tags instead, and also addon programmers weren't asked to use /tags. If both things (well, they go hand in hand) would have happened before the move to a new framework in /trunk, things would have been easier. Plus, files.wowace.com should probably not use /trunk either. In other words, even the most active members of this community just let it happen and watched the thousands of non-devs update all their apps with one click from /trunk. Which was no problem as long as /trunk was stable (and if I may remember, when moving to BC we had all BC addons in /branches for quite a while - I cant remember having seen the rock-based addons in /branches for more than just a few days).
This is not about how SVN systems usually work, but this is how a community of gamers (out of which the vast majority aren't developers and have no clue what SVN is) deals with the fact that all of a sudden things change (and break).
The argument "/trunk is not for non-devs" has become irrelevant, it's like the police happily watching people over-speed at the highways for years and from one day to the other collecting the drivers licenses of 90% of the people using the highway because they were over-speeding.
PS: oh, the usage of /tags is rather complicated with all the external embeds - unless all the libraries were available in /tags too. Which they aren't.
We didn't "just let it happen"... the whole thing started out as a way to take the load off the SVN for the users that wanted access to the current betas. It took off, and people started DEPENDING on beta versions of everything. The system needs reworked, the updater needs to default to releases only (betas as an override) and the devs need to start tagging out versions that are tested and working. Everyone has to do a little something here to make the situation better. The whole Rock-conversion issue is along the same lines... ckk probably should have done it in branch, but that was his mistake.
Devs and users are dependent on trunk being stable, and that's never been a good thing. Trunk will break, often, we need to break everyone of the bad habit of running off trunk for their addons... you sure as hell don't do your development on the production server all your users are using day in and day out, same should be applied here.
Quote from maia »
PS: oh, the usage of /tags is rather complicated with all the external embeds - unless all the libraries were available in /tags too. Which they aren't.
Actually, a decent tag script could either change the externals to a revision-specific external, or just export the externals (at the target revision) directly into the tag. Moving libs into a tag system would be much better though, especially on the testing and support end with addons (I tested with lib-x.x, so that's what's embedded in it, and it's a tested tag of the lib).
I think there's been a lot of learning from this these recent events both from users as well as developers. Everyone can only learn from them.
i love this idea
Libs in and of themslfs are "Published Works" they need to be included in the /tags. Also considering that if files.wowace.com (NOT WAU as it pulls from the files site rss) will be pulling from /tags, libs need to be included to allow advanced users to do their thing
to further Saynt's idea (parser for example and prat for examples)
/tags
-/Parser
--/4.0
---/<LIB FILES>
/tags
-/Prat
--/1.0
---/<Addon FILES>
i sugest this to keep the main /tags folder un cluttered.
Not my idea, just a linked picture :). I seem to recall 'back in the day' that most addons were kept in the Branch then moved to the Trunk when more stable, but I could be wrong. What is unfortunate is that the convenience of Updaters make it so easy for people to upgrade, most users think these are released, stable Addons.
My other two pennies - The average Joe Troller/User/Updater doesn't always know what they're getting into. If I were new here, I might have expected UberNewAddon 2.0 to be in a release state - it doesn't say 2.0b/2.0a/testing or any mention of beta anywhere, even the thread. Not that this was really that bad, but it goes to show a little communication goes a long way.
With the Updaters so widespread now, you have to play to the lowest common denominator.
I think there's been a lot of learning from this these recent events both from users as well as developers. Everyone can only learn from them.
Good example. In fact if dev on ace was always done in branch (as that example shows) then trunk would be a good canidate for "stable beta" and could be used as it is now more reliably by users....
Now if you'd like to imagine how things really happen with ace's SVN... move all the yellow boxes into the trunk path and color them all green.
Actually, a decent tag script could either change the externals to a revision-specific external, or just export the externals (at the target revision) directly into the tag. Moving libs into a tag system would be much better though, especially on the testing and support end with addons (I tested with lib-x.x, so that's what's embedded in it, and it's a tested tag of the lib).
This will be defeated by the auto-upgrading feature of the libraries.
Say your addon Foo uses and has been packed with LibBar-1.0 rev 10. If the user installs another addon that uses LibBar-1.0 rev 40. Your addon will end up using LibBar-1.0 rev 40, period.
Or... we should use a proper versionning scheme where shouldn't be two versions of LibBar-1.0 but rather LibBar-1.0 and LibBar-1.1. This way your addon uses LibBar-1.0 and the other addon uses LibBar-1.1, no conflict. The cost is that there will be several versions of the same library loaded in-memory.
Going back to the idea of releasing from tags. I think the naming scheme could be :
/tags/AddonName/stable/X.Y
where :
- AddonName is the addon name (surprise!),
- X is the addon major version, updater should NOT upgrade major version automatically,
- Y is the addon minor version, updater should upgrade minor version automatically.
Major version increment should be used when some breakage is expected (like, say, going from Ace2 to Rock... :P)
The "stable" subdirectory allows authors to create other tags that would be ignored by the packaging script.
e.g. for my addon CastYeller, each version would be tagged :
The script would package the latest minor of each major, e.g. :
/tags/CastYeller/stable/1.3 -> CastYeller-1.3.zip
/tags/CastYeller/stable/2.2 -> CastYeller-2.2.zip
If all non-devs know nothing about /trunk /tags etc "we" could silently change the script to only release tagged versions. The problem is that i think it's inconvenient to check out addons from tags or branches just to beta test them.
We clearly need a easy way (like WAU) to update addons to beta versions, but should everyone be possible to? The idea of WAU only downloading beta if configured to do will not work... all silly users that know nothing and whine when their addons break will configure it to use betas anyway.
nicky... it's a simple matter of method not an end user problem or something they need to hack
this is a svn -> files.wowace.com script and WAU pulls from files site/rss. IMHO if you want betas use an svn client. I'll accept that as a viable stopping block. if your not techie enough to run a svn client you prolly don't need to be using beta versions. granted it is a bit far fetched.. but it's the same idea.
prolly what will end up happening is that they'll throw up another rss feed on files site for beta versions from the trunk.
-tags are for stable releases
-branches are for other authors to play around and for you to test things that you may or may not include.
-trunk is for main development - alpha / beta
Adirelle, the lib upgrading is there for good reason, we don't want to circumvent it. What we DO want is to keep un-tagged libraries out of tagged addons. So if a user only pulls updates from tags, they know that both the library and the addon have been tested and won't explode like a few addons in trunk are doing lately *cough*
Ckk is making a great case for this whole thing right now, even if he doesn't intend to. If we didn't have users pulling down those addon while they are mid-transition to libraries that aren't tested and stable, we wouldn't have a rash of users coming in here complaining that their fubar is gone and they don't like Rock's config.
Tagging can work beautifully with embeds and their self-upgrading... as long as people don't let beta libraries get out to the users (haven't I said this a few times already?). What you propose with the "stable" path is a perfect way to do the tags. When a new tag is made, the old "stable" is renamed to it's rev and a new "stable" takes it's place... or maybe we just do the normal overwriting and let devs go back in the SVN log if they want an old one for some reason. So I guess it would be more like a "stable trunk" than tags, in that only one version of each addon or library major would exist there at any given time.
How about this: Add a new root path. We have tags for full-blown release versions. We have trunk for "bleeding edge", and we add stable for "tags" of betas. WAU (and the file packager) could default to stable and have overrides to get trunk. Tags (releases) would be pushed out to WoWI/etc. The "stable" path would essentially be a mirror of trunk, except users know that they *shouldn't* be getting something that will blow up on them, but it is still "beta" quality.
[dropped a long post since Tekkub answered most points...]
Quote from tekkub »
When a new tag is made, the old "stable" is renamed to it's rev and a new "stable" takes it's place... or maybe we just do the normal overwriting and let devs go back in the SVN log if they want an old one for some reason. So I guess it would be more like a "stable trunk" than tags, in that only one version of each addon or library major would exist there at any given time.
Though this is just kinda SVN "good practice", subdirectories of /tags/ should NEVER be renamed/commited to/whatsoever. Once a tag is created, it is sealed for ages. So every stable tag could be referenced by stable (or probably trunk) addons without the risk of breaking externals at some point in the future.
Quote from tekkub »
How about this: Add a new root path. We have tags for full-blown release versions. We have trunk for "bleeding edge", and we add stable for "tags" of betas. WAU (and the file packager) could default to stable and have overrides to get trunk. Tags (releases) would be pushed out to WoWI/etc. The "stable" path would essentially be a mirror of trunk, except users know that they *shouldn't* be getting something that will blow up on them, but it is still "beta" quality.
Why not, though :
1) it's not SVN-orthodox :p
2) I don't know if it is technically possible to "tag" to an existing path.
Tagged libraries still raise a question : how and by who beta versions of libraries would be tested ?
2) I don't know if it is technically possible to "tag" to an existing path.
As far as i have understood a tag is just a copy of something in the tag directory. Everything on a SVN is just copies in different directories. I may be very wrong though.
1) so? :)
2) first time is a copy operation, after that it'd be a merge (just like a branch). That's why I kinda veered away from calling it tags there at the end.
As for who tests? I think we've had a fairly decent past with libs, it's just the time when someone really should be working in a branch that bites us in the ass. I'd say, with addon it's the dev's discretion. With libraries, let the library sit in trunk and get tested a bit by other devs for a few days before pushing it to "stable"... don't just commit a rash of "opps fixed that" patches after a change... those commits should stay in trunk.
If you really do want to stick to "SVN-orthodox", we should get people OUT of the habbit of working in trunk. I can say from "real world" experience that when you have many people all working in trunk at the same time, it's not fun. On the Ace SVN people don't run into conflicts... but I hate it when my boss is working in trunk, he always screws shit up for me. It's much better to work in a branch, get it stable, and merge that to trunk.
Hell, that model also means no changes need to be made to the repo or the updaters... maybe we should encourage people to do active dev in branches and push stable versions over to trunk?
It is a good idea tekkub. But i don't think it will work because people are to lazy to test addons in branches. You simple have to beg them to. I think that was part of ckknights problem. No one was testing his branches, although they may have been there a bit too short time. But it will go a lot faster to find bugs in your addons by moving it to trunk so it will be tested.
I consider branch as not working / alpha and trunk as beta. When the trunk is stable you release it to the masses.
If you really do want to stick to "SVN-orthodox", we should get people OUT of the habbit of working in trunk. I can say from "real world" experience that when you have many people all working in trunk at the same time, it's not fun. On the Ace SVN people don't run into conflicts... but I hate it when my boss is working in trunk, he always screws shit up for me. It's much better to work in a branch, get it stable, and merge that to trunk.
Hell, that model also means no changes need to be made to the repo or the updaters... maybe we should encourage people to do active dev in branches and push stable versions over to trunk?
.. ya branch is for alpha testing of any sort and dev - branch is for a "stable" version of something but not release quality. and ya... clue-by-4'ing dev's that don't do this is a good idea.
so whats the conclusion here... ya'll seem to be dancing around the same 4 concepts
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I think much of the drama of the last few days could have been eliminated had there been seperate beta and release repositories. When the WAU first came online it was nice for many dev's of addons and beta testers wanting to be on the bleeding edge. However, many guilds now require Threat-1.0 - it is updated often so we need to run WAU often. WAU is mainstream and very popular. It is common for peeps to run WAU, login to run raids or group activities that require those precious addons that we have come to love. Sudden global changes effect our game play and could effect our ability to raid, PVP or whatever.
Duel repositories would eliminate dramatic changes and dramatic reactions.
I propose that every developer makes stable releases, and that users use these releases instead of testing (wich is to be used for testing).
Multiple repositories are not needed for this. Instead, if WAU would use /tags instead of /trunk, people will enjoy less updates (good) and tested addons, provided that developers test their addons before release.
Theoretically I agree - but it doesn't really seem like anyone asked the guys behind the updater apps to use /tags instead, and also addon programmers weren't asked to use /tags. If both things (well, they go hand in hand) would have happened before the move to a new framework in /trunk, things would have been easier. Plus, files.wowace.com should probably not use /trunk either. In other words, even the most active members of this community just let it happen and watched the thousands of non-devs update all their apps with one click from /trunk. Which was no problem as long as /trunk was stable (and if I may remember, when moving to BC we had all BC addons in /branches for quite a while - I cant remember having seen the rock-based addons in /branches for more than just a few days).
This is not about how SVN systems usually work, but this is how a community of gamers (out of which the vast majority aren't developers and have no clue what SVN is) deals with the fact that all of a sudden things change (and break).
The argument "/trunk is not for non-devs" has become irrelevant, it's like the police happily watching people over-speed at the highways for years and from one day to the other collecting the drivers licenses of 90% of the people using the highway because they were over-speeding.
PS: oh, the usage of /tags is rather complicated with all the external embeds - unless all the libraries were available in /tags too. Which they aren't.
Devs and users are dependent on trunk being stable, and that's never been a good thing. Trunk will break, often, we need to break everyone of the bad habit of running off trunk for their addons... you sure as hell don't do your development on the production server all your users are using day in and day out, same should be applied here.
Actually, a decent tag script could either change the externals to a revision-specific external, or just export the externals (at the target revision) directly into the tag. Moving libs into a tag system would be much better though, especially on the testing and support end with addons (I tested with lib-x.x, so that's what's embedded in it, and it's a tested tag of the lib).
http://en.wikipedia.org/wiki/Subversion_%28software%29
I think there's been a lot of learning from this these recent events both from users as well as developers. Everyone can only learn from them.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumi love this idea
Libs in and of themslfs are "Published Works" they need to be included in the /tags. Also considering that if files.wowace.com (NOT WAU as it pulls from the files site rss) will be pulling from /tags, libs need to be included to allow advanced users to do their thing
to further Saynt's idea (parser for example and prat for examples)
/tags
-/Parser
--/4.0
---/<LIB FILES>
/tags
-/Prat
--/1.0
---/<Addon FILES>
i sugest this to keep the main /tags folder un cluttered.
My other two pennies - The average Joe Troller/User/Updater doesn't always know what they're getting into. If I were new here, I might have expected UberNewAddon 2.0 to be in a release state - it doesn't say 2.0b/2.0a/testing or any mention of beta anywhere, even the thread. Not that this was really that bad, but it goes to show a little communication goes a long way.
With the Updaters so widespread now, you have to play to the lowest common denominator.
Good example. In fact if dev on ace was always done in branch (as that example shows) then trunk would be a good canidate for "stable beta" and could be used as it is now more reliably by users....
Now if you'd like to imagine how things really happen with ace's SVN... move all the yellow boxes into the trunk path and color them all green.
...and delete the blue boxes... ;)
No no, those two can stay... just add 48000 more green boxes.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis will be defeated by the auto-upgrading feature of the libraries.
Say your addon Foo uses and has been packed with LibBar-1.0 rev 10. If the user installs another addon that uses LibBar-1.0 rev 40. Your addon will end up using LibBar-1.0 rev 40, period.
Or... we should use a proper versionning scheme where shouldn't be two versions of LibBar-1.0 but rather LibBar-1.0 and LibBar-1.1. This way your addon uses LibBar-1.0 and the other addon uses LibBar-1.1, no conflict. The cost is that there will be several versions of the same library loaded in-memory.
Going back to the idea of releasing from tags. I think the naming scheme could be :
/tags/AddonName/stable/X.Y
where :
- AddonName is the addon name (surprise!),
- X is the addon major version, updater should NOT upgrade major version automatically,
- Y is the addon minor version, updater should upgrade minor version automatically.
Major version increment should be used when some breakage is expected (like, say, going from Ace2 to Rock... :P)
The "stable" subdirectory allows authors to create other tags that would be ignored by the packaging script.
e.g. for my addon CastYeller, each version would be tagged :
/tags/CastYeller/stable/1.0
/tags/CastYeller/stable/1.1
/tags/CastYeller/stable/1.2
/tags/CastYeller/stable/1.3
/tags/CastYeller/stable/2.0
/tags/CastYeller/stable/2.1
/tags/CastYeller/stable/2.2
...
The script would package the latest minor of each major, e.g. :
/tags/CastYeller/stable/1.3 -> CastYeller-1.3.zip
/tags/CastYeller/stable/2.2 -> CastYeller-2.2.zip
Any thoughts/ideas/comments ?
We clearly need a easy way (like WAU) to update addons to beta versions, but should everyone be possible to? The idea of WAU only downloading beta if configured to do will not work... all silly users that know nothing and whine when their addons break will configure it to use betas anyway.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumthis is a svn -> files.wowace.com script and WAU pulls from files site/rss. IMHO if you want betas use an svn client. I'll accept that as a viable stopping block. if your not techie enough to run a svn client you prolly don't need to be using beta versions. granted it is a bit far fetched.. but it's the same idea.
prolly what will end up happening is that they'll throw up another rss feed on files site for beta versions from the trunk.
-tags are for stable releases
-branches are for other authors to play around and for you to test things that you may or may not include.
-trunk is for main development - alpha / beta
@ adirelle - good idea
edited because im AFK
Ckk is making a great case for this whole thing right now, even if he doesn't intend to. If we didn't have users pulling down those addon while they are mid-transition to libraries that aren't tested and stable, we wouldn't have a rash of users coming in here complaining that their fubar is gone and they don't like Rock's config.
Tagging can work beautifully with embeds and their self-upgrading... as long as people don't let beta libraries get out to the users (haven't I said this a few times already?). What you propose with the "stable" path is a perfect way to do the tags. When a new tag is made, the old "stable" is renamed to it's rev and a new "stable" takes it's place... or maybe we just do the normal overwriting and let devs go back in the SVN log if they want an old one for some reason. So I guess it would be more like a "stable trunk" than tags, in that only one version of each addon or library major would exist there at any given time.
How about this: Add a new root path. We have tags for full-blown release versions. We have trunk for "bleeding edge", and we add stable for "tags" of betas. WAU (and the file packager) could default to stable and have overrides to get trunk. Tags (releases) would be pushed out to WoWI/etc. The "stable" path would essentially be a mirror of trunk, except users know that they *shouldn't* be getting something that will blow up on them, but it is still "beta" quality.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThough this is just kinda SVN "good practice", subdirectories of /tags/ should NEVER be renamed/commited to/whatsoever. Once a tag is created, it is sealed for ages. So every stable tag could be referenced by stable (or probably trunk) addons without the risk of breaking externals at some point in the future.
Why not, though :
1) it's not SVN-orthodox :p
2) I don't know if it is technically possible to "tag" to an existing path.
Tagged libraries still raise a question : how and by who beta versions of libraries would be tested ?
As far as i have understood a tag is just a copy of something in the tag directory. Everything on a SVN is just copies in different directories. I may be very wrong though.
2) first time is a copy operation, after that it'd be a merge (just like a branch). That's why I kinda veered away from calling it tags there at the end.
As for who tests? I think we've had a fairly decent past with libs, it's just the time when someone really should be working in a branch that bites us in the ass. I'd say, with addon it's the dev's discretion. With libraries, let the library sit in trunk and get tested a bit by other devs for a few days before pushing it to "stable"... don't just commit a rash of "opps fixed that" patches after a change... those commits should stay in trunk.
If you really do want to stick to "SVN-orthodox", we should get people OUT of the habbit of working in trunk. I can say from "real world" experience that when you have many people all working in trunk at the same time, it's not fun. On the Ace SVN people don't run into conflicts... but I hate it when my boss is working in trunk, he always screws shit up for me. It's much better to work in a branch, get it stable, and merge that to trunk.
Hell, that model also means no changes need to be made to the repo or the updaters... maybe we should encourage people to do active dev in branches and push stable versions over to trunk?
I consider branch as not working / alpha and trunk as beta. When the trunk is stable you release it to the masses.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium.. ya branch is for alpha testing of any sort and dev - branch is for a "stable" version of something but not release quality. and ya... clue-by-4'ing dev's that don't do this is a good idea.
so whats the conclusion here... ya'll seem to be dancing around the same 4 concepts