Would it be best practice, for now, to use a branch or fork for projects that are getting the Warlords update treatment?
Sure, that's one method, but I was curious if I simply put the ToC at 60000, is the packager smart enough to flag an AddOn for WoD on curse.com? Or leave it as a branch and point users to it via the project description? I don't like the second method as most users either can't or don't read.
If you incorporate your changes into the trunk, and they are not backwards compatible, then you should either:
a) plan on no updates to your addon for live WoW between now and when WoD hits and just leave your updates in Alpha status (no tagging for the packager to pick up)
or
b) make your code backwards compatible with live
My suggestion would be to make a WoD branch. This is, after all, one of the reasons for using a version control system.
If you need to make changes that affect users on the current version of WoW, you'll be able to do so without version-checking acrobatics - just remember to merge the live branch into the WoD branch afterward, though, so you don't have an insane amount of conflicts when the time comes to merge WoD into the main branch.
If you use a mercurial repository, you need to make sure that the TIP commit is always on your default branch.
I recently created a WoD branch, and it was packaging and going to the curse client. I had to make a dummy commit on the default branch so that TIP pointed to it in order to fix the situation.
The URL will always be the same for the repository - it's the same repo; a branch isn't its own repository, unless you're doing funky stuff or making a complete fork to create a new codebase. Though branches on SVN is something I've never dealt with, so I have no advice there.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorSure, that's one method, but I was curious if I simply put the ToC at 60000, is the packager smart enough to flag an AddOn for WoD on curse.com? Or leave it as a branch and point users to it via the project description? I don't like the second method as most users either can't or don't read.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiuma) plan on no updates to your addon for live WoW between now and when WoD hits and just leave your updates in Alpha status (no tagging for the packager to pick up)
or
b) make your code backwards compatible with live
-
View User Profile
-
View Posts
-
Send Message
Project AuthorIf you need to make changes that affect users on the current version of WoW, you'll be able to do so without version-checking acrobatics - just remember to merge the live branch into the WoD branch afterward, though, so you don't have an insane amount of conflicts when the time comes to merge WoD into the main branch.
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI recently created a WoD branch, and it was packaging and going to the curse client. I had to make a dummy commit on the default branch so that TIP pointed to it in order to fix the situation.
-
View User Profile
-
View Posts
-
Send Message
Forum ModeratorHow is TortoiseSVN, WowAce, Curse, and the Curse Client supposed to know which one I am doing commits to?
I see I can edit the repo and change the name of the clone. Is that what I'm supposed to do?
How can you tell I've never cloned a repo, or created a branch? LOL.
-
View User Profile
-
View Posts
-
Send Message
Project AuthorRight-click > TortoiseSVN > Branch/tag...
To path: "/branches/yournamehere"
Log message: "creating branch yournamehere"
Create copy in the repository from: HEAD revision in the repository
Check "Switch working copy to new branch/tag"
OK
Now your working copy is linked to the branch, not the trunk. All commits will go to the branch.