vasl-developers / vasl

Virtual Advanced Squad Leader
http://vasl.info/
GNU Lesser General Public License v2.1
66 stars 28 forks source link

Changed propertiesFilter so that concealed sw would not be highlighted (issue 1802) #1843

Closed geezer09 closed 1 month ago

geezer09 commented 1 month ago

This pull request includes a small change to the ASLBrokenFinder class in the VASL module. The change modifies the filter expression used to determine which pieces are considered broken.

derimmer commented 1 month ago

Our normal practice would be to add this to the next beta first, and then include it in the next official release.

The final beta for VASL6.6.9 has been released and 6.6.9 will officially release around November 1st.

I would propose to include this the first beta for 6.7.0 which will probably release early in the new year with the official 6.7.0 release around April 1, 2025.

geezer09 commented 1 month ago

Oh okay, I plan on contributing more going forward. How should I proceed? If i get write access I could create branches for each individual issue, or do you want to create a 6.7.0 branch where I can push my code?

derimmer commented 1 month ago

Oh okay, I plan on contributing more going forward. How should I proceed? If i get write access I could create branches for each individual issue, or do you want to create a 6.7.0 branch where I can push my code?

Glad to hear that you are happy to contribute. You are most welcome.

I having been doing most of the coding of late so to the extent that we have "rules, best practices, or the way we do things", they are really just how I have chosen/learned to do things and are not meant to control or limit anyone. So I am very open to ideas about how we can best use github.

I believe that I can give you write access and will try to do so after I send this message.

If you look at the wiki pages, you will see some advice on how to configure an IDE, obtain the code and push up changes. Always a bit out of date but mostly workable.

I believe it suggests creating new branch for each issue. Personally, I have gone away from that and tend to create a branch for each new version (I have been issuing two versions a year, April and November). When I was doing 90% of the coding, that worked. I have just created a branch for my work on 670 (dev670) which I will start tomorrow.

So, either branch-per-issue or branch-per-version, it is your preference. We can make both work. Our past practice has been for new-to-us coders to submit pull requests for review for a few months to ensure that they are not putting the code base at risk. If you are comfortable with that, we can proceed that way. Depending on your coding skills, you may be ready to push your own requests pretty quickly. I am not big on control so happy to work as you wish.

We do have an issues list. I would encourage you to use it and to feel free to work on anything you see on the list. Be sure to assign the issue to yourself if you do decide to work on one in order to avoid duplication. I have found the Bug and Enhancement labels to be particularly useful since I tend to do a bug fix version (spring) and a new features version (fall) - again that is just my practice and not a hard and fast rule. Also, don't hesitate to add your own issues. I work on stuff that I want to work on and I encourage you to do the same.

That's enough for now.

Cheers.

Doug

derimmer commented 1 month ago

@geezer09 I believe i have now given you write access to vasl and several other repos.

geezer09 commented 1 month ago

As per the comments, I will close this pull request and create a new branch with the recommended changes. I will create another pull request at a later date.