I'm aware of that one. It's a wrinkle listed here, that needs to be ironed out at some point.
Ok we will follow semantic versioning. It's funny, I think I should have tagged the latest release as 0.50a instead of 0.51a, because it makes it seem like we have completed all our goals for 0.51.
Hey I see that we can attach issues to milestones! Cool ☭
Posted by capristo, Jun 23, 2015 at 10:28 am
Planning for Release
in forum IVAN Development
Awesome, thank you everyone for the contributions in the SDL 2 update.
My vote would be to go ahead with C++11 and drop DJGPP. It's a shame but as someone who writes PHP all day and sees the huge benefits of newer PHP versions, I can appreciate the need to update the code.
My vote would be to go ahead with C++11 and drop DJGPP. It's a shame but as someone who writes PHP all day and sees the huge benefits of newer PHP versions, I can appreciate the need to update the code.
Posted by capristo, Jun 13, 2015 at 11:53 am
Planning for Release
in forum IVAN Development
Awesome, murlock! Thanks so much for contributing. Just submit a pull request when everything's ready
Posted by capristo, Apr 28, 2015 at 10:36 am
I've almost definitely seen bear traps. Not sure about a mine
Posted by capristo, Apr 11, 2015 at 11:45 pm
Bug Reports
in forum IVAN Development
Similar to JoKe's comment in the shoutbox, I think I also noticed that the reddish light didn't go away when my stuff burned away (leather gloves of dexterity 
)
)
Posted by capristo, Apr 6, 2015 at 10:54 am
I need to put the banana and pickaxe back in. Just posting this to remind myself
Posted by capristo, Mar 29, 2015 at 7:20 pm
official website BUGS thread
in forum Website News
Whoops, I messed something up with the quick edit divs. I'll fix that soon
Posted by capristo, Mar 20, 2015 at 10:11 am
I like polypiling too, especially for the carrots. Seems like carrots are generated pretty commonly, they just get eaten up so quickly by the other monsters. Usually after polypiling I end up with ~40 perception, which is awesome
Posted by capristo, Mar 11, 2015 at 3:25 pm
Does ESP detect based on the Intelligence value then? I wonder if it's possible for a person to have their Int drop so low that they aren't detected with ESP. Maybe through a big hit to the head or a -5 helmet of brilliance or something
Posted by capristo, Mar 5, 2015 at 11:00 am
Planning for Release
in forum IVAN Development
I think the fire system is enough to warrant a 51. Maybe we should set the goal to be 0.6 instead?
Posted by capristo, Mar 4, 2015 at 4:46 pm
Planning for Release
in forum IVAN Development
Back on the topic of releases. There was some discussion on Github here
https://github.com/Attnam/ivan/pull/21
Seems like the concensus is that Attnam/master is the working space, NOT the "stable" version. Stable versions will instead be released as tags.
I can fork Attnam/master into capristo/master and then make my own changes. After I have tested my changes, I submit a pull request to Attnam/master which is merged in so that everybody else can test.
If I have a larger feature that will take a long time to complete, I can branch my own fork into capristo/FireSystem. Then when I am comfortable with this feature being complete, I should first merge into capristo/master, and then submit a pull request as usual to Attnam/master.
Then to release specific versions, we should use git tagging because that is basically what it was built for and what Github supports out of the box. For example, after my capristo/FireSystem branch has been merged in, we tag this as version 0.51. All commits up to this point are now released as version 0.51 and can be downloaded as a zip. Then if we fix a few bugs related to the fire system, we can release this as 0.51.1. The next batch of bugs is tagged 0.51.2 and so on. Then when we add the next big feature, call it 0.52.
We should stick to semantic versioning as much as possible:
0.51.2
0 - major release
51 - minor release, increment when adding new features
2 - patch, increment when releasing bug fixes which don't add new functionality
That was designed for APIs. I am ok with using a letter to denote the patch instead, e g. 0.51a, 0.51b
https://github.com/Attnam/ivan/pull/21
Seems like the concensus is that Attnam/master is the working space, NOT the "stable" version. Stable versions will instead be released as tags.
I can fork Attnam/master into capristo/master and then make my own changes. After I have tested my changes, I submit a pull request to Attnam/master which is merged in so that everybody else can test.
If I have a larger feature that will take a long time to complete, I can branch my own fork into capristo/FireSystem. Then when I am comfortable with this feature being complete, I should first merge into capristo/master, and then submit a pull request as usual to Attnam/master.
Then to release specific versions, we should use git tagging because that is basically what it was built for and what Github supports out of the box. For example, after my capristo/FireSystem branch has been merged in, we tag this as version 0.51. All commits up to this point are now released as version 0.51 and can be downloaded as a zip. Then if we fix a few bugs related to the fire system, we can release this as 0.51.1. The next batch of bugs is tagged 0.51.2 and so on. Then when we add the next big feature, call it 0.52.
We should stick to semantic versioning as much as possible:
0.51.2
0 - major release
51 - minor release, increment when adding new features
2 - patch, increment when releasing bug fixes which don't add new functionality
That was designed for APIs. I am ok with using a letter to denote the patch instead, e g. 0.51a, 0.51b