| 1 |
[quote]We actually do very well with what we have, we have a very stable product under constant development from engine to art, coding to balance. We keep a live, playable, excellent product through all of that.[/quote]
|
1 |
[quote]We actually do very well with what we have, we have a very stable product under constant development from engine to art, coding to balance. We keep a live, playable, excellent product through all of that.[/quote]
|
| 2 |
\n
|
2 |
\n
|
| 3 |
Yes, thats true, the game is great and its moving forward. There is no question about it. My point was, it takes a lot more effort than required to do so. Also, I'm sure you could use more developpers to improve things even more/faster. But how things are currently done, adding more developpers means adding more work for "core devs" just to keep things under control. And its not possible to try new things if you can't be around #zkdev at all time, because when a need for a minor release happen, everyone gets crazy ("where is A?" "did he test his things?" "can we release it?" "lets revert everything he made").
|
3 |
Yes, thats true, the game is great and its moving forward. There is no question about it. My point was, it takes a lot more effort than required to do so. Also, I'm sure you could use more developpers to improve things even more/faster. But how things are currently done, adding more developpers means adding more work for "core devs" just to keep things under control. And its not possible to try new things if you can't be around #zkdev at all time, because when a need for a minor release happen, everyone gets crazy ("where is A?" "did he test his things?" "can we release it?" "lets revert everything he made").
|
| 4 |
\n
|
4 |
\n
|
| 5 |
My comments were not really advocating for git over svn, but more about using branches. Of course the example given was about using git because that's what cool kids currently love, but the "workflow" was the important theme.
|
5 |
My comments were not really advocating for git over svn, but more about using branches. Of course the example given was about using git because that's what cool kids currently love, but the "workflow" was the important theme.
|
| 6 |
\n
|
6 |
\n
|
| 7 |
Maybe
git
isn't
currently
easy
to
use
for
mirosoftees,
but
I
guess
this
is
about
to
change:
http://techcrunch.
com/2013/01/30/microsoft-announces-git-support-for-visual-studio-team-foundation-server-and-service/
|
7 |
Maybe
git
isn't
currently
easy
to
use
for
microsoftees,
but
I
guess
this
is
about
to
change:
http://techcrunch.
com/2013/01/30/microsoft-announces-git-support-for-visual-studio-team-foundation-server-and-service/
|
| 8 |
\n
|
8 |
\n
|
| 9 |
Hours *after* I made my post in this thread:
|
9 |
Hours *after* I made my post in this thread:
|
| 10 |
[quote]
|
10 |
[quote]
|
| 11 |
r9640 Unrevert stuff non-UI stuff (mission_orbital drop speed, morph priority, new scythe icon)
|
11 |
r9640 Unrevert stuff non-UI stuff (mission_orbital drop speed, morph priority, new scythe icon)
|
| 12 |
r9639 Unreverted luaui updates involving ui. Before anyone makes a stable, host a springie game with latest test. Choose advanced and host zk:revision:####
|
12 |
r9639 Unreverted luaui updates involving ui. Before anyone makes a stable, host a springie game with latest test. Choose advanced and host zk:revision:####
|
| 13 |
r9638 VERSION{v1.1.2.12} Reverted incomplete keybinds work. Everything should go back to normal.
|
13 |
r9638 VERSION{v1.1.2.12} Reverted incomplete keybinds work. Everything should go back to normal.
|
| 14 |
r9637 Reverted Epic Menu to before r9447.
|
14 |
r9637 Reverted Epic Menu to before r9447.
|
| 15 |
r9636 Revert previous.
|
15 |
r9636 Revert previous.
|
| 16 |
r9635 Reverted previous. Epicmenu - restored code. Integral menu - uses zk_keys.
|
16 |
r9635 Reverted previous. Epicmenu - restored code. Integral menu - uses zk_keys.
|
| 17 |
r9634 Revert back to r9606 (v1.1.2.9) with the exception of r9609, r9615, r9624, r9627, r9630.
|
17 |
r9634 Revert back to r9606 (v1.1.2.9) with the exception of r9609, r9615, r9624, r9627, r9630.
|
| 18 |
r9633 Revert previous commit.
|
18 |
r9633 Revert previous commit.
|
| 19 |
r9632 VERSION{v1.1.2.11} Revert to prev stable.
|
19 |
r9632 VERSION{v1.1.2.11} Revert to prev stable.
|
| 20 |
[/quote]
|
20 |
[/quote]
|
| 21 |
\n
|
21 |
\n
|
| 22 |
Who is able, by reading those commitlogs, to say what is currently in the repository? Its hard to follow progress. Similarly, its hard to just see what changes made through up to the release point.
|
22 |
Who is able, by reading those commitlogs, to say what is currently in the repository? Its hard to follow progress. Similarly, its hard to just see what changes made through up to the release point.
|
| 23 |
\n
|
23 |
\n
|
| 24 |
Maybe there is no advantage in this project to use 1 branch per feature (or rather, its overcomplicated). But using 1 branch per release and ensuring that not everyone commits to the release branches (by actually having 1 dev + 1 curated release branch per version) would prevent such back-and-forth jitter. And when moving stuff from the dev branch to the release branch, it would be a good time to review tickets. There is no point for a dev to close tickets when you commit a fix that may be reverted later because of an urgent need of minor release and which may not be "unreverted" subsequently. Whose job is it, to "unrevert the reverts"?
|
24 |
Maybe there is no advantage in this project to use 1 branch per feature (or rather, its overcomplicated). But using 1 branch per release and ensuring that not everyone commits to the release branches (by actually having 1 dev + 1 curated release branch per version) would prevent such back-and-forth jitter. And when moving stuff from the dev branch to the release branch, it would be a good time to review tickets. There is no point for a dev to close tickets when you commit a fix that may be reverted later because of an urgent need of minor release and which may not be "unreverted" subsequently. Whose job is it, to "unrevert the reverts"?
|
@devs: bug tracker