Versioning for Ruth and Roth #32
Comments
|
I think all these suggestions are good. I also agree that calling it "version n" is preferable for the reason you give. I suggest when it settles down that a version of the text of the issue, removing the questions when settled, is added to the repository as a top level file called something like "version-Info.txt". |
|
Seems reasonable to me! |
|
As long as you can explain it to the artists who are not programmers :) |
|
If we look on the SL marketplace for "Ruth" we find something like:
1,4,6) I don't know which version this could be I have found not even one product with a name containing the string "Ruth 2.0" and a proper version string like "RC3" (but I have to confess that I didn't search for it longer then 20 minutes) RC, Release Candidate: My suggestion is to drop the "2.0" string as part of the name completly (the repository name also doesn't contain it), so the name becomes "Ruth" and "Roth". We then could use a proper version string for example "2.4" for the next (defacto) release so if you write "name" + "version" it becomes "Ruth 2.4" (or "Ruth v2.4" if we want that "v"). This also means that there are no differences between internal and external references. |
|
Leona.. we really can't just call the female avatar "Ruth" as Ruth is the long standing name for the default Second Life and OpenSim classic avatar. That was why the original updated avatar project was named "Ruth 2.0". We need to think of that as a project name rather than a version. I do agree that confusion reigns where people have uploaded and made their own versions... which to be clear was the original aim of the project founders. But most do make it clear whether they are based on Ruth 2.0 RC#1, Ruth 2.0 RC#2 or Ruth 2.0 RC#3 or Roth 2.0 RC#1, which are the only versions of Ruth that are current based for the builds, boxes or mods. I also think that Serie and the team should call things "version n" from now on... and consider the previous RC#n as Ruth 2.0 version n or Roth 2.0 version n. |
|
Well, you know for example the famous Microsoft Word? The first version arrived ~1985 it is called Microsoft Word till today. You can be sure that current version has nothing to do with the first version but nevertheless it is called "Word". So why shouldn't we stick to the name "Ruth" as a synonym for a female standard avatar? The versions number should make the differnce very clear. In fact that is exacly what version numbers are made for? |
|
The '2.0' in 'Ruth 2.0' is not a version, although it looks like one, and hence the confusion. It is marketing-speak not unlike the old 'Web 2.0' phrase. Sean made the obvious change for his incarnation (RuthToo) that keeps the spirit of the name and yet has its own identity. If we make a change I believe it needs to be like that. I agree with Austin that we can/should not just drop the '2.0'. One possibility is to make the '2.0' visibly more part of the name, such as 'Ruth-2.0' or 'Ruth2', ie eliminate the space so it looks more like a single name. that would leave us with 'Ruth-2.0 v2.4' or 'Ruth2 v2.4'. The latter looks better to me but is not quite as obvious that it is the same as 'Ruth 2.0'. Ada: I often interpret 'release' to refer to integrated things that are tested and packaged as a unit, where 'version' is the tracking for the component things. This is far from standard and the two are often used interchangeably by many people (including me in what I proposed above! grrr). I don't think the distinction here is as important as it might be in some projects. |
|
IMHO: 'Ruth2' is also a good suggestion to prevent confusion between the name and the version. |
|
I don't think we should add 2.x into the version number Serie. I think it should be Ruth 2.0 v4. We should consider the earlier RCn as each being the equivalent of vn. So Ruth 2.0 RC#3 is also Ruth 2.0 v3. More input on whether to rename Ruth 2.0 as Ruth2 is needed... I personally think its too late to do that. Seeing this as the equivalent of "Web 2.0" as Serie noted is best I think. |
|
I am happy to go with 'Ruth 2.0 v4', it is overall simpler to just count rather than attempting to apply meaning to the x.y.z versioning formats. |
|
When we were working on earlier versions of Ruth, we had more than one person working in the Blender files - we need labeling to keep track of them as well. When it was working well, it was version numbers for various files on UV mapping, for example, plus the artist's name, maybe another set of version numbers when a different set of artists (with some overlap) was working on vertex weighting. It wasn't all that well organized, but as various artists came and went and came back again, we could usually find what we needed. It looks to me that not all of the blend files nor all of the dae files ended up in this GitHub, and I don't know what happened to the missing ones. And Shin sent me some files outside of GitHub, asking me not to share them. I think all those Ruth and Roth Blender files are irrelevant now that we're moving into Blender 2.81 - essentially starting over, with Shin's topology more of a guideline than a final model. Release Candidate number was for when Shin was ready to put a package together inworld - mesh, HUDs, textures, half a dozen or more people's efforts. What is industry standard for a project like this? I'm open to any system that can take the human foibles into consideration, along with the marketing labels that we don't have much control over. It's never going to be perfect. :) |
|
LeonaMorro commented yesterday:
Just a minor note. RC#3 is exactly the correct nomenclature per the original Shin Ingen release of Ruth 2.0 RC#3 as can be seen in this readme: As far as what is used going forward, I'm okay with whatever you all decide. My only suggestion might be to adopt RuthTwo instead of Ruth2, but I'm even okay with keeping Ruth 2.0. I will, of course, continue to use my RuthToo name. The virtual worlds where it is used tends not to care what's a version or release or release candidate number. Most just want to know which clothes will fit it and occasionally if this is the newest one. ~Sean Heavy |
My fault, sorry. Thank you for the info. |
|
I have been thinking more... Serie suggested...
I also now think we might be better off taking the opportunity of a fresh repository, fully sourced version and perhaps splitting the repositories to change the name to Ruth2 and Roth2. I would suggest that the previous RC#N be vN not v2.nN - as that will be confusing too. Would we ever get v3.1 and if so would people start referring to that as Ruth3? Ruth2 would be the "project name" going forwards and for compatibility we would have Roth2 (even though there was no Roth 1 :-). In world for parts we tend to start them with ru2_ and ro2_ so that's already in good shape, and we can soon alter read me and wiki titles, etc. RuthAndRoth as the git organization name, forum names, discord channel, for our in world (OSGrid) region, SL and OS groups names etc still works okay I assume. We might make the split repository Ruth2 and Roth2 and leave the old Ruth repository in place emptied except for a readme pointing with links to the split newly named repositories. Hence, under this suggestion the next "versions" would be Ruth2 v4 and Roth2 v2. |
I believe you can just rename the repository. No need to create a new one. This seems overkill to me, however. There seems to be a struggle here against the original numbering scheme, where the RCs were leading to a release. Now that the RCs have sat for so long that people have been using them as releases, you want to just use them as previous versions. Just go ahead and do that: Ruth2 v3, and continue from there. I doubt it will confuse anyone. The rest is just going to be bikeshedding. |
|
Joseph, my struggle is exactly what you mention, that the RC marks are de facto releases and we have basically been treating them as that. The work Ada is doing on the mesh now is making these bodies significantly different from what we had last year. I think this is the best time to get these things right and not have debt to fix later. I don't think we are into bike shedding quite yet, I know I am still new enough to this group to not have completely internalized the different ways artists and creators and developers make use of this project. The further repo split (as opposed to just renaming Ruth repo) is useful to get rid of the large number of obsolete binaries being carried around in the git repo history. This is an example of why using git for tracking binary stuff isn't really the right tool; we moved things like the skins out already. The split maintains history for the files we keep and eliminates it for the ones that we really do not need. What Austin is suggesting is exactly what I think we should do. I have one more round of family holiday this weekend, I'll try to sneak in an update to the test splits in my personal GitHub space with everything we've discussed in mind. Sean, thanks for the suggestion of RuthTwo, but I think that is very close to your RuthToo, which I do not want to step on, I think it was an inspired name! Even if Ruth2 and RuthToo are pronounced the same they look enough different to not be quite as easily confused. |
|
To follow up from yesterday, I did update the test extraction for Roth2 (https://github.com/seriesumei/test-Roth2) and Ruth2 (https://github.com/seriesumei/test-Ruth2) and included a list of the files that were moved and renamed at the bottom of the main README. I tried the naming that Austin suggested, let me know of that works or if we should adjust it. |
|
Looks good to me... should we make the move and do this in the main repository now? Anyone against that? A little renaming of the archive branches may be useful too after that. e.g. to archive-ruth2-v3. And perhaps we should leave in place a repository named "Ruth" with just a Readme in it pointing at where things have moved to and mentioning that RC#n has been renamed version n. |
|
I intentionally did not do anything with the existing archive branches, I figured we have links pointing to them we may want to just leave that where it is, we could rename the branches. We can rename the repo and GitHub should do proper re-directions since we will not re-use that name. Also, I was planning to remove the things moved from the original repo so there is no confusion about which copy is current. Once we are done making changes there we can also set the archive bit and it will become read-only. I'll do some testing on this part too soon... This is a major change, I would like to get a consensus before making things permanent. I will go ahead and finish preparing the Licenses part of the References repo (the test is at https://github.com/seriesumei/reference-test) since that seems unlikely to change much, except for the name of the current 'SecondLifeAvatar' directory from Ada's Contrib area. |
|
I've updated https://github.com/seriesumei/test-Reference one last time with some input from Ada (Edit: and went ahead and created https://github.com/RuthAndRoth/Reference). Everything that was in "Contrib/SL Resources" has been sourced from original upstream locations and are available expanded in the repo so they can be used directly. They are a bit scattered about, we can add a list to the README if they are too hard for people to find. |
|
Todays update: Hearing no objects I have pushed the test-Ruth2 and test-Roth2 repos to their final home in the RuthAndRoth project: I am working through removing the migrated files from the original Ruth repo, the current incarnation of that is in my account in an 'rm' branch at https://github.com/seriesumei/Ruth/tree/rm. I will create an archive branch before merging any removals; we should consider what to do with the remaining files. I would prefer to not rename or re-use the existing repo, we should migrate the useful remaining things (like the ElfEars!) into something like an Extras repo. |
|
Looks good to me. I agree its best to keep the existing Ruth repository and make sure its readme explains the history of the repository from the Outworldz version, through the ingen-lab one to Ruth here and then the split. I also agree it makes sense to split out the extras, attachments and any clothing that we don’t include in the “base”. I assume the Ruth2/Accessories will pretty much all be shifted to such an Extras repository... except maybe for the essential bentohandrelaxedP1.bvh animation? But my feeling is that basic underwear we ought to include in the core in world distribution, like Shin’s boxers for Roth, should maybe stay in the core Roth2 and the equivalent in Ruth2. |
|
When the new repositories are finished(are they?) I suggest that a contribution road map is made and published. I am very confused about the management of the project (also pretty new to the project). These contribs folders are confusing to me. Instead of contribs folders, I suggest making a release branch. Let people make their working branch from the master. Once they have content worth merging with the master do a pull request. Set the merges so a specific number of people ok it. If as a group, the changes are rejected then that individual could think again or fork the project. I feel this would allow for better progress. |
|
Thanks for the reminder to wrap this up, here's where things stand:
I agree that the Contrib directories can be a bit wild, part of the issue is we have a range of familiarity with git in our contributor base that I felt pushing too much process in would be a hinderance to some. That said, we have used PRs to do some things, I pushed the Ruth repo cleanup as a PR to get some final feedback and review on it before merging it. I would certainly support using that workflow for people who understand it as it is what I am used to doing too. I am a little reluctant to get too deep into keeping too many working branches in the main repos as they tend to accumulate and we forget what state they are in. I think Github's PR workflow is better for workspaces as those working branches are kept in our personal repo forks. As for a contribution roadmap, most of what is here is because someone wanted to work on it, very little is assigned. One place this can break down is in deciding what is 'official'. We do not have a formal process aside from bringing up topics or proposals here and seeing who shows up to talk about them. If you have specific ideas about a roadmap I'd love to hear them. |
|
The point I am really making is that a "process" does need deciding on and laying down. I fully understand many will not know git workflows, but perhaps a link to the workflow decided on or something written down in the repository readme? What I don't see is any way for someone to come into the repository and see what the proposed changes are, assess the quality of the work and agree to integrate the change or not. For example, I opened a scripting issue a while back, people commented, but with no system, in place to most, it is probably already forgotten about. Whatever system is decided on someone wanting to contribute should have a clear path to getting that contribution considered. There should be a clear process for project leads (or the group as a whole) to see proposed changes, assess them and then integrate or not. |
|
It's all volunteers who do what they like, when they have time. And some contributions are not compatible with other contributions, so we have had a process for evaluating them, that sometimes even works. When Shin was doing most of the testing he had a rating system for vertex weighting, for example - if 96% of the off-the-shelf animations worked, done. Tastes vary, so there are quite a few unofficial forks out there. Ai has been helping me look at drafts of the armature collada export issue from Blender 2.8x. We'll organize something for the next draft of vertex weighting, all volunteers welcome. UV mapping has been trickier and more organic to share, as it wasn't a step by step progression. Put out a version, someone else puts one out that's a lot better for the fingers and toes but worse at the shoulders. A third artist figures out how to fix a seam. We talk about feet for a while. Someone (me, that time), combines the ideas. Volunteer testers take a look with all their favorite skins and we collectively decide which problems we let go and which are deal breakers. Anyway, that's why, for a lot of it, we need to keep contributions separated by contributor. When one version is as good as it gets, it'll go into a "Release" or some such folder. For scripting, I'm not the person to talk to - I haven't done any of it. And shouldn't. :) |
|
Ada what your describing would still to my mind be better done with branches/forks and version control used as it should be. Eg. You want to fix for UV map of the feet.
Now when someone else comes along they want to work on the shoulders, they clone the master, which now has your updates there already. The process means others are easily aware of what is being worked on. They can see the progress that has been made while you work. If you have an especially tricky task with multiple ideas, you can all see each others approach, work out which is best or if they can be merged. Now add release branches into the mix so everyone can see at a glance how items/code looked when the last release was made. They can also see the current state. I am just talking about adding structure, transparency and clarity. It would also help others not working on the project directly, but who are working on related items. |
|
An issue though is that the core Ruth2 and Roth2 assets are mostly created and changed in external tools like Blender and OpenSim and we use GitHub to store the latest versions in binary/blob form. Often one team member is taking the responsibility for some asset at any one time and others are testing, making suggestions, raising issues and showing possible alterations. We use the GitHub issues to talk about things, and anyone interested in that issue weighs in. the personal named contribitions areas are useful in that regard a it allows people to mention assets in these issues and have them all contained in GitHub rather tha using external repositiories or web site which might not be accessible to all or disaaaprea in future. Here is my take on the current process, which I actually think works fairly well for us as a small community just now... We have the "RuthAndRoth" GitHub "organization" and can add team members and admins to that at any time. Currently the admins are Fred Beckhusen (who created the organization), Ai Austin and Serie Sumei. That offers backup for unforseen drop outs and they can add other admins as team members interests change. Fre Beckhusen keeps us all straight on licensing and we ofte refer suich questiosn to him, he can be considered the elad on that. Serie is experienced with GitHub and currently takes the lead on the GitHub repository structure, making branches and archive areas, etc. This is often driven by a discussion in the issues. Anyone can input to thoseissues. As active members come along they can be added with direct commit rights to the repositories. Issues are the main way in which discussions take places, bugs or development path issues are raised, etc. Discussions there often take the form of one team member taking the lad at one time, and others putting in inputs. This can include referring to changed assets, which the team member is encouraged to add to the Contrib/name folder to make them accessible for testing by others. We work in cycles running up to the preparation of a versioned "release". Up to Ruth2 v3 (previously named Ruth 2.0 RC#3) and Roth2 v1 previously named (Roth 2.0 RC#1) Shin Ingen took the lead on the preparation of the releases taking on board contributions from a lot of other people. The next release is to be called Ruth2 v4 and Roth2 v2 and that is what the community is working on at the moment. Outside of GitHub we also have a "shared" avatar on Second Life and in OSGrid/OpenSim named "RuthAndRoth Resident" and an OSGrid/OpenSim region "RuthAndRoth". Ai Austin currently looks after this and host the regions on his servers making OAR backups available to RuthAndRoth admins as backup, and when things settle after the next release the OAR will be openly accessible. The current plan is for the RuthAndRoth avatar in Second Life and OpenSim to be the avatar that boxes up the releases and makes them available in world. Then an IAR of those items will also be made available. |
|
I will say this then back off on the issue. Nothing you just said Austin promotes using folders, or not in my view. Let's assume I wanted to fix the thigh issue on Roth and you're acting as a tester. I make a new roth_thigh development branch, cloned from master. I will then clone the new branch to my HDD, work on the idea, commit after every change, then when I hit a testing point, push to the development branch. Then you would come along and clone that dev branch to your HDD. Do your tests, note what you found etc. You find an issue, I fix it. I push to the branch, you pull the update to your had and test it. Once it's ready, a pull request for the branch is made. Now others come to look at what's been done; they can see details about every stage of the development on the commit comments. They can also if they wish clone any stage of those changes to their HDD to see test it. The issue is that right now when someone comes into the repository it is very difficult to see what has changed since the last release, instead of agreed on and completed changes already being in the master branch. The changes are buried somewhere is someone's contribs folder. They then have to crawl through the issue messages to find where. Let's assume they do, copy it and start working on adding to that work in their own contribs folder. Someone else does the same. At some point, someone has to try and make sense of everything. There is no centralised view of changes agreed on and the current work completed. |
We have an interesting situation in the name of this project containing what looks like a version string: Ruth 2.0. Historically the releases have been labelled RC1, etc, which implies not having an actual release, which is probably accurate, they were more like checkpoints really.
I am proposing here a naming convention for release versions that I hope is not too different from what folks are used to seeing but gets specific and hopefully prevents some confusion from happening.
The project name is colloquially Ruth 2.0, with Roth 2.0 coming later. This Github project name fortunately does not have the numbers in it but there is some value in keeping the name, so let's do that (unless there are strong feelings here I have not heard about yet). We should try to not use the words version or release in connection with the 2.0 in the project name.
Ruth: We have generally agreed that the current work on Ruth is going to be called 4-something. Previously there were RC2 and RC3 so 4 is natural to follow. I propose to stop using the letters 'RC' since that means Release Candidate to most people and we are really talking about a release or version identifier. I would suggest instead talking about 'release 4' or 'version 4' with my personal preference for using 'version' because of the tendency to abbreviate it as 'v4'. Using 'r4' or 'R4' looks a lot like 'RC4', although that may actually be a benefit. Thoughts?
Roth: Basically the same discussion as above, we should use the same process, only the current work is for v2. This should be the only time we will have Roth 2.0 v2 or something that looks redundant.
Internal references: For things like file names, git tags or branch names I propose that we simply leave out the '2.0' everywhere. A tag for the next Roth release might look like 'Roth-v2'.
I am interested to hear what folks think. I am thinking about this from a software developers point of view, does it make sense to others too? If not, how can it be improved?
The text was updated successfully, but these errors were encountered: