These are chat archives for UltraStar-Deluxe/USDX

19th
Jul 2016
basisbit
@basisbit
Jul 19 2016 00:50
We could do Version 1.3.3.7beta
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:51
build number?
basisbit
@basisbit
Jul 19 2016 00:51
Nah, just kidding. How about 1.3.2?
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:51
don't know
basisbit
@basisbit
Jul 19 2016 00:51
As 1.2 was used by world Party and the cmd build
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:52
I actually like the short versioning 1.3, but with a existing beta/alpha, it's isn't possible.
basisbit
@basisbit
Jul 19 2016 00:52
And my oder test builds for other users to test Werke 1.3.0 and 1.3.1
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:52
btw. there are questions. scroll up ;)
basisbit
@basisbit
Jul 19 2016 00:53
Sorry, have to get up in 5 hours for work and am also finishing a business presentation for tomorrow morning
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:53
ah k. 1.3.2 for this one (with beta (b) just like 1.0.1?
basisbit
@basisbit
Jul 19 2016 00:53
Sounds good
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:54
btw. uploading an example repo for having a consistent history
basisbit
@basisbit
Jul 19 2016 00:55
OK. I don't undestand why that is necessary, but well, whatever :smile:
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:55
source control
basisbit
@basisbit
Jul 19 2016 00:56
Yes?
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:56
yes. no?
basisbit
@basisbit
Jul 19 2016 00:57
Whatever ;-)
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:57
does the worldpartymod exist as source (git/svn)?
basisbit
@basisbit
Jul 19 2016 00:57
Nope
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:57
patches?
basisbit
@basisbit
Jul 19 2016 00:57
Nope
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:58
multiple zips with changelog?
basisbit
@basisbit
Jul 19 2016 00:58
They mostly ignored GPL
No changelog at all
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:58
you got the "final" version, that'S t?
basisbit
@basisbit
Jul 19 2016 00:58
I Bad to threaten to sue them for a couple of month before I got some in-development code
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:59
lol
basisbit
@basisbit
Jul 19 2016 00:59
Yes :(
RattleSN4K3
@RattleSN4K3
Jul 19 2016 00:59
i aksed because i currently only merged the big commit as "Merging WorldPartyMod"
basisbit
@basisbit
Jul 19 2016 01:00
I hoped to be able to work together with them but they didn't want to understand the idea of open source development
RattleSN4K3
@RattleSN4K3
Jul 19 2016 01:00
would be good to have at least some versions to understand the reason of some code changes
basisbit
@basisbit
Jul 19 2016 01:01
Just call it merging third party mods
RattleSN4K3
@RattleSN4K3
Jul 19 2016 01:01
is it "free source", do whatever you like? joking :(
it's only a temp one, can re-create it
basisbit
@basisbit
Jul 19 2016 01:01
Vor free beer?
RattleSN4K3
@RattleSN4K3
Jul 19 2016 01:01
only takes a bit
was the CMD mod open source?
basisbit
@basisbit
Jul 19 2016 01:03
Yes up to some version in 2011
See usdx svn repository
RattleSN4K3
@RattleSN4K3
Jul 19 2016 01:03
it was the creator of vocaluxe, right?
basisbit
@basisbit
Jul 19 2016 01:03
Some of them
Mostly brunzel
As far as I know
RattleSN4K3
@RattleSN4K3
Jul 19 2016 01:04
to sad so many alternate versions exist in such open source program
ultrastar was even worse
basisbit
@basisbit
Jul 19 2016 17:15
sorry, but please stop spawning so many issues :-\
try to aggregate them and use irc / gitter
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:17
issues keeps it organzied and easy to follow, + write it down with referencing various things. And it states what any dev can concentrate on, without following any async communication
basisbit
@basisbit
Jul 19 2016 17:27
then please aggregate them. you are spamming the email box of everyone who is following the project and the issue list grows / gets unusable for others
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:30
issue by issue. agregate them would nullify its purpose. if someone feels being spammed by push mails which that one has opted in, they should opt-out (or change their filter).
basisbit
@basisbit
Jul 19 2016 17:30
and for minor issues, please fix them right away without creating any additional issues especially if writing the issue + having two others read it takes about as much time as just directly fixing it.
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:32
if i'd "fix" them directly, I would work on my own without getting the consents of other devs. I did these things on purpose, not just "creating a log what I do"
basisbit
@basisbit
Jul 19 2016 17:37
as I said, please aggregate the issues in the future.
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:37
why if they are not aggregate-able per se
the only reason you state to aggregate them is because of spamming the email box (and having the read other issues). but that's pretty much the purpose of notifications. either you like th read them (opt-in) or not (opt-out). If I aggregate them, it's still likely the same wall of text you'd have to read in order to fully follow the discussion.
basisbit
@basisbit
Jul 19 2016 17:40
thats the thing! they are aggregatable. create one for languages, one for themes, one for documentation. Use separate issues for functional changes or to mark that you are working on certain changes.
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:41
they are all multiple issues, which can be accepted or decline on its own.
basisbit
@basisbit
Jul 19 2016 17:41
that is not the only reason, you are currently the only one who still knows what all your issues are for. this is not a good way for working together as a distributed project
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:41
for instance the romainan and gaelic/galician issue
if there was a case why the romain lang was removed, it clears clsoes that issue. but it wouldn't solve the issue of the gaelic/galician case.
basisbit
@basisbit
Jul 19 2016 17:43
then use checklists within the language issue and use the issue starting post for keeping track of that
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:43

you are currently the only one who still knows what all your issues are for

i mostly describe if the title doesn't state what the issue is all about.

it ends into two discussion on the same issue.
basisbit
@basisbit
Jul 19 2016 17:46
no one will participate the discussions because that wastes too much time. don't work on too many place at the same time. github issue tracker is to much limited to be used the way you use it currently
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:46
I don't think so.
it's the same principle like with commits. keeping it short, tracable/ confirmable, etc.
the github issue tracker is good enough to also work as backlog for everyone, additionally to what is it intended .
basisbit
@basisbit
Jul 19 2016 17:52
ok, if you want, keep using the issue tracker then way you do, but please don't expect me to keep track of them and reply to questions there because I don't have enough time for that and still want to spend some time on actually coding on USDX and especially other projects
anyways if you are going to fix an issue, please assign yourself to it so other devs know not to spend time on that
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:54
most of the "question" issues are urgent.

anyways if you are going to fix an issue, please assign yourself to it so other devs know not to spend time on that

i already do so.

basisbit
@basisbit
Jul 19 2016 17:55
thanks :) just wanted to make sure
RattleSN4K3
@RattleSN4K3
Jul 19 2016 17:56
I don't do it if there's no other dev/member participating. then I might try to look into and fix it on my own, closing that issue.
* side by side to other things
basisbit
@basisbit
Jul 19 2016 18:05
regarding version numbering, how about this: http://semver.org/
so it would be 9.8.7-dev
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:07
Yep. That's mostly for releasing. the problematic part is defining what the dev version should state, the possibly unstable codebase
"9.8.7-dev", i'd understand that as internal ("dev") release
basisbit
@basisbit
Jul 19 2016 18:08
so that would work as text in the version file?
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:08
plain text, yes.
basisbit
@basisbit
Jul 19 2016 18:09
ok, then there is the answer for #79
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:09
?
you mean "trunk"?
basisbit
@basisbit
Jul 19 2016 18:10
you didn't like trunk, so use dev instead
"9.8.7-dev"
regarding #78 , I'd suggest not having a plaintext readme as that will be additional work to keep it current and nowadays everyone can browse a website or read formatted .md
or the pdf
for #77 , all files that are available are in the git repositories somewhere. as far as I know none of the active developers has any additonal files.
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:13
I still prefer "+".
1.3.2 < 1.3.2+ <1.3.3 < 1.3.3+ < 1.4.0 < 1.4.0+ < 1.5.0
"dev" should be convserve for actual releases such as your 1.3.0 and 1.3.1 versions
basisbit
@basisbit
Jul 19 2016 18:14
ok, then there is your decision. do it :) ("Giddy-Up")
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:15

regarding #78 , I'd suggest not having a plaintext readme as that will be additional work to keep it current and nowadays everyone can browse a website or read formatted .md
or the pdf

it's for the actual game. and yes, that would be a bit more work. but not that much. the readme can be the documantation. the README.md does have to state everything important for the deveoploment (such as guidelines etc., notes, abouts, how-tos).

basisbit
@basisbit
Jul 19 2016 18:15
regarding #75 , I have no idea how to react to this. not enough information. if you are in doubt regarding that, use a pull request and another dev will take a look and answer
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:16

for #77 , all files that are available are in the git repositories somewhere. as far as I know none of the active developers has any additonal files.

too bad. i hope we can get into contact with the original authors someday, somewhen

basisbit
@basisbit
Jul 19 2016 18:17
regarding #74 and #73 , I don't know these languages and don't really care, feel free to do what is right in your opinion or leave it as it is. If that is a problem for a user, they'll eventually open an issue for that
I physically met with some of the original devs and most of them don't have the free time or interest any more. We'll have to solve these things on our own.
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:20

regarding #75 , I have no idea how to react to this. not enough information. if you are in doubt regarding that, use a pull request and another dev will take a look and answer

it'S the aggregated (:wink:) issue for everything related to the big merge commit. i've sceen alot of things are removed without even mentioning why, and some things were violating the license. that issue is used as blacklog for checking what things have to be reverted and what things should stay "changed". the issue is also created to have a discussion related to that specific topic /changes. it's not possible to create a PR for such complex merge, it would be a big chunk of code, or changes. Some things covering that problem were already changed with the recent commit regarding the installer files.

ok, then there is your decision. do it :grinning: ("Giddy-Up")

the "VERSION" would be more for the codebase, but if it should exist already before the next release, I could add it as milestone issue

basisbit
@basisbit
Jul 19 2016 18:22
#69 we should leave the import feature there for now and whenever we have something that works to replace this, remove the old stuff and replace it in the main menu. for developing that new feature, a branch should be used
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:23

a branch should be used

yep. but branching isn't that good in git, therefore non conflciting, good and stable changes could be done to the master, and keep the branch on par/up-to-date

basisbit
@basisbit
Jul 19 2016 18:24
agree
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:26
someday wiki pages should exist ^^
basisbit
@basisbit
Jul 19 2016 18:26
regarding the version, yes, only for the codebase. public/advertised version numbers will be 1.3-beta, 1.3, 1.4-alpha,..
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:26
the official releases had the patch/release number included
1.1.0, 1.0.1
basisbit
@basisbit
Jul 19 2016 18:27
yes, but always was advertised as usdx 1.0 and usdx 1.1
that is what people will remember
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:28
but that'S what I meant, asking it several times here and in issues.
if in 1-2 weeks the new version is released as "1.3", will the next version be relased as "1.3.3"?
or "1.4" already
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:35
the medley support fully comes from the worldpartymod?
basisbit
@basisbit
Jul 19 2016 18:36
no
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:36
k.
basisbit
@basisbit
Jul 19 2016 18:36
was partly implemented already in usdx 1.1
further developed in the challenge/medley mod
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:36
usdx svn seems to have it. but not fully implemented
tags are read and thus not considered to be custom, therefoe the writing of that ini file will strip these.
ini=txt
basisbit
@basisbit
Jul 19 2016 18:37
and completely different implementation in world party
must have missed that during the big merge, sorry
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:38
not sure if the worldpartymod has it. but usdx svn doesn't have it and the git repo as well
might be an issue of the worldpartymod as well
(official)
basisbit
@basisbit
Jul 19 2016 18:39
will be at home in ~ 10 minutes. will be back then. can't chat and drive
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:39
lol
the whole code can be refactored a lot, to feature more OOP. but that's too much.
RattleSN4K3
@RattleSN4K3
Jul 19 2016 18:47
isn't PREVIEWSTART a very old tag?
ah. likely part of the USDX 1.2 trunk