Versions and Milestones (and tickets)

[beni]

We had quite a discussion the other day about version numbering, milestones and the use of tickets.

As far as I was concerned I didn't like the lack of organizational structure in the project, which would be provided by milestones and tickets. If there is even a lack of organization and - if there is - if it is a problem, is of course a point where we may disagree.

A fact is, that at the time I brought this up, tickets were hardly used and milestones were not used at all.

As the organization might not look as bad when you are working at Orxonox and regularly meet with everybody else, for somebody from outside of the project it is quite hard to find out more detailed information about Orxonox.

You may argue, that there are no people at the outside of the project, except the student, who again meet regularly each week to discuss and work on Orxonox. Therefore proper organization is useless, time wasting and too complicated.
On the other hand, there might be no outside people exactly because of this lack of transparency. But again, this is a point where we disagree.
Of course you can also argue, that regardless of organization Orxonox is still in a state (or already?) where it is impossible to get a detailed view of the project.
And in the end you may not want everybody to be able to mess up the code.

In a related discussion we came to the question if it makes sense to have a milestone each semester, as the students need to finish their projects anyway and also because the projects of the students often do not complete a state of the game, which should be called a milestone in the development.

Together with the question of sense-making milestoning the question of version numbering came up as well. As we increased the version number every semester since we started again from scratch, we should be at version 0.3. This can also be seen in the rather poorly maintained milestones. Now since we may use the milestones to describe a certain state of the game, the question is how we do the version numbering. And an even more important question: What is the current version? Greenman told me, he does not think that the current state of the game satisfy the version number 0.3. I on the other hand, am not satisfied to call the current state v0.0.

We may discuss this forever and we might never agree completely, but we need some kind of decision.

Maybe that whole thing may be summarized in following questions:

• Do we need a change in organization?
• If yes: How would you handle milestones and the version numbering?

Maybe I did not cover the whole subject. I wouldn't mind at all if you would bring up more points of view.

[x3n]

Yeah, 0.3 is a bit high. Let's call it 0.0.3.
We change to 0.1 as soon as there is a first "playable" state that will be released. With playable I mean, we should have a nice level (we need a new skybox, the current one doesn't fit the license), enemies, pickups, a gameplay (with scores, some rules, a predetermined finish) and different ship models (this is already possible, we just didn't had the time yet). This state is reachable with a comparable small amount of changes.

But using versions means assigning tickets to a version, which is a lot of work, because this have to be changed every time the number changes. But it's possible and I'll do it if we agree on this.


But I really don't see a point in using milestones. They're just a collection of tickets with a specific goal within one version. But as long as we change the version every semester, there's absolutely no need for this. Usually it tooks up to 2 semesters to finish a topic.


Also I don't see how versions and milestones solve the problem with extern people. You could create thousands of milestones and increase the version with every commit and there's still a lack of information for extern people.
And additionally I don't think there are many people out there, willing to work for Orxonox. Not yet. This will change if we have a sufficient good game, an active community and a satisfying gameplay. But now we're just one of millions of development teams. People only work if there's a benefit. Enhancing a game you like IS a benefit. But Orxonox isn't yet in a likeable state.

[beni]

Alright, fair enough. The suggestion with the 0.0.3 sounds reasonable, since we didn't really use the third version number anyways. How would you increase this version number? By semester or by milestone?

About the milestone. It's true it's just a collection, but I understand milestones literally: Milestones on a journey. This means each milestone comes after the other. As tickets are just random tasks in a large bucket, the milestones bring them into a linear perspective. We would group tickets which have to be done first into the first milestone, tickets which depend on the tickets from the first milestone are put into the second one, etc. So solving a ticket which is not in the current milestone may not even be possible or just senseless.

All in all it gives us a line of what has been, what is and what will be soon. That's the advantage I see with the milestones.

But using versions means assigning tickets to a version, which is a lot of work, because this have to be changed every time the number changes. But it's possible and I'll do it if we agree on this.

Well, if we increase version numbers by semester, this would be true. That does not make sense that much in my opinion.[/quote]

[x3n]

But we have a lot "it would be nice if someone does xyz" tickets or possible PPS topcis that weren't chosen. Some of them are absolutely unnecessary für any milestone, but they should be done somewhen. Where would you place those tickets?

[greenman]

I think it's difficult to integrate milestones into the pps, because students may not be able to or don't want to solve certain tickets. iif we just give them a choice of the tickets in the current milestone they might be unsatisfied with the ticket they get.

0.0.3 sounds good to me and i fully ack with x3n's opinion of increasing the version to 0.1 when we reach a playable state.

i suggest increasing the version number by 0.0.1 each term and by 0.1 if we have serious improvements.

[1337]

Thank you guys for bring up this topic. We really need to make a decision before the start of the new semester.

As for my part, I fully agree with x3n's opinion about the versions. Usually an increase of the patch version (+=0.0.1) doesn't make interface breaking changes. However this doesn't make sense at all yet. It would also mean to always maintain multiple branches and the trunk at the same time. But once we get something serious, we might come back to this common strategy.

There's something else I would like to express: There should not only be PPS-tickets for students but we should also advertise the other ones. I see a lot of small coding stuff that just never reached the ticket system, but could be done by a student in maybe two or three weeks. This may not be as satisfying as a larger project, but personally I would like to that as PPS student.

Anyway, while talking about tickets and PPS students, I think milestones could make sense. But I also don't think it's worth it. My suggestion is simply grouping tickets by priority only. Plus there are a few guys leading the PPS and the coding/modeling work itself. They could organise the distribution of the right tickets (it doesn't have to accurate, just common sense; e.g. you cannot choose a ticket that has unfinished dependencies).

As for the versioning process I also recommend common sense. Usually a version bump makes sense somewhere between two semesters. But I would not urge this at all. When the time feels right, make a version bump. Coincident might (especially with the current development) make these bumps compellingly occur every semester, but that's just a guess

Coming back to milestones, I think it's just a question of whether we really need this kind of over organisation. Look at OGRE:
http://www.ogre3d.org/wiki/index.php/Roadmap
I agree, OGRE is ages more mature than Orxonox, but I can clearly see that their milestones are the minor (+=0.2) version changes. Even for v2.0, there won't be considerately larger changes than for v1.8.

I hope I was able to deliver my opinion in a constructive way. But do not weigh it too much since I don't really have to live with the decisions we make here..

Btw: I have created about 16 new tickets from my todo list. There are more to come and as soon as I'm about done, I shall create a forum post the the links to all my tickets.

[beni]

Wow thank you for participating in the discussion so eagerly. I was expecting less enthusiasm after the last discussion.

In my opinion a version increase (+0.0.1) after one semester does not make sense that much. I think it makes sense to totally separate the PPS and the ETH semesters from our development cycle.
I think a larger merge back into the trunk would satisfy the conditions of a version increase, but not just a certain amount of time past on the project.

Choosing from the pool of open tickets to create a list of PPS projects is acceptable in my opinion. We do not need to choose from the current milestone, as the PPS leaders will know what makes sense and what not.

I would then suggest, that the PPS tickets would be added to the current milestone, but we could solve this in another way as well.

About the 0.1 version bump I would really like to have a milestone. I think we should finally agree on a state where we think that we want to release the game, even though they may be a lot of things which are far from perfect. Making further milestones does not make sense of course.

About the 0.2 step version process of Ogre: As far as I know Ogre has the version system which is unstable at an odd number and is stable at a even number. I don't really like this system and I wouldn't be in favor to use this with Orxonox.

I think we should use milestones (or maybe just one or two at the time) to define our larger goals. So everybody knows what state we wanna reach. I'm sure there are also some differences in our opinions there.
For the PPS I think we can leave the milestones away and just add tickets for each project, or as I once suggested, add multiple tickets for each project to help the students to organize their work.

Many thanks to Reto for the new tickets. I think this is very useful and valuable. I think most ideas satisfy the need for a ticket. If we find out later that the idea is stupid we just close the ticket. Having to many tickets is not possible in my opinion.

[1337]

In my opinion a version increase (+0.0.1) after one semester does not make sense that much. I think it makes sense to totally separate the PPS and the ETH semesters from our development cycle.
I think a larger merge back into the trunk would satisfy the conditions of a version increase, but not just a certain amount of time past on the project.

My opinion exactly.

I think we should use milestones (or maybe just one or two at the time) to define our larger goals. So everybody knows what state we wanna reach. I'm sure there are also some differences in our opinions there.
For the PPS I think we can leave the milestones away and just add tickets for each project, or as I once suggested, add multiple tickets for each project to help the students to organize their work.

Do not underestimate the laziness of students (even if you tell them a hundred times). Most of the students would just like to do their work and maybe say some words at the convention. So in the end the devs will have to keep most of the projects up-to-date themselves.
However I agree on defining larger goals if we can clearly see them, which might not always be possible, but it certainly starts to get possibler every day, because of the current development stage. So it might be possible... But I leave this up to Fabian and Oli because it will probably be their precious time spent on organising milestones.

Many thanks to Reto for the new tickets. I think this is very useful and valuable. I think most ideas satisfy the need for a ticket. If we find out later that the idea is stupid we just close the ticket. Having to many tickets is not possible in my opinion.

I took the liberty of creating rather more tickets than is really necessary because I understand them as suggestions since the ticket system has a comment function, so that one ticket is like a thread in this forum. Some of my new tickets may be closed entirely, others edited, mainly because many of them or rather vague ideas of my todo-list.

[beni]

I've got nothing more to add to Reto's post. In general I agree with your ideas and in the end the decision is at the persons who have to actually deal with the consequences.