Thanks to everyone.
I plan on parsing the dates from the file, give a warning if the date is invalid (and set the date to today)
I will give the opportunity to select whether you want comparison to be on full dates or on years.
I will assume that empty field on “to date” means same year as “from date”, and will handle the string today as current date.
1 Like
I am confused.
The source code in your repository has the Black reformatting and uses the Probably Alive utility built into Gramps.
The source code in the gramps-project/addons-source repository does not have either of those improvements.
However, both are marked as version 0.2.11
What is the current version? And how does @GaryGriffin know when to publish a new version to the Addon Manager?
Don’t be. It is probably me who have misunderstood something.
When @GaryGriffin published the addon, he told me to make a ticket in the bug tracking system, for the improvements I intended to do. When done, I could commit the changes, and in the commit mention the bug tracking ID.
So I am doing the improvements, but I have learned from earlier projects to commit often, so I don’t want to pollute the addons-source tree with all my “intermediate” commits, so I update my own repo.
When I think I am done tinkering, I will copy my source to my cloned version from the addons-sorce repo, and make a commit with comments about whar has been done, notify Gary, and hopefully make some users happy.
I thought this was the way to do it, but I should have thought about the version numbers.
Please let me know if I am doing this in a wrong way - and I will change my workflow accourdingly
1 Like
So the current version is what is in then gramps repo, and the version in my repo is an intermedient work copy
My “own copy” is often committed, when I have something that doesn’t throw a syntax error in my face
1 Like
When you commit (or just after whatever upload verification process you use) to your personal online repository, could you increment the version by 0.0.01 ? (Since you are the owner of the Repository, you can edit the file directly online. Your GitHub Destop should note the local needs an update to sync.) Otherwise, those of us trying to beta test have to tediously compare source code line-by-line to determine when to update.
Gary and Nick have mentioned that the addon publishing tool (make.py) increments the versioning automatically to avoid collisions. But it cannot hurt for developers to keep a hand on the tiller in case autopilot misses an obstacle.
The version number should be updated.
My normal IDE (Lazarus and fpc) does this by default every time I compile.
And I know the make.py script should do this, but since I develop and play in my own sandbox, I do not use the script, but do stuff manually. I just started to use Visual Studio Code for my Python work, and didn’t know about black before you mentioned it. I really have a lot to learn.
And of course I will keep an eye on the version number in the future.
Doesn’t it make sense to play in my own sandbox/repo until I have something I think is worth testing?
1 Like
Absolutely! I don’t commit updates very often to my experiment in my online repository. (Except when I am interactively bug testing with someone who has a problem I cannot re-produce locally.) Normally, my updates to the repository are more like Windows “Restore Points” … so those restore points need careful versioning identifiers.
Thanks. I have had issues with bad hard drives in the past, and lost weeks of development.
So I commit often, and use tag to identify when I have a working version
1 Like
There is no PR, so nothing to even consider.
My rule of thumb is to review if the PR has been open for a week with no activity. In the case of @kmikkels there was a lot of activity after the PR was created, so I waited until activity ended and he thought it was ready for release.
I do not care whether the version number was incremented in the gpr file. The build will increment it automatically. Personally I don’t increment the version for the gramplets I code but let the build process do it for me at the time of publishing.
I do see the concern in differentiating when testing the PR.
4 Likes
Committing often is best practice. Developers who do that usually commit often to their local repository, not online to GitHub. Once your local changes are satisfactory to you, then you push it up to your fork either as a bunch of commits, or better, as one commit to GitHub by squashing your changes locally using the interactive rebase command.
Tagging is common in other SCM systems, but in Git tags are used differently and are really hard to delete permanently once they are published to shared repositories. Typically they are used for long-term annotation, not for work-in-progress type of usage. For that, you can use branching (very cheap with Git).
Git offers so many options, it may be a bit overwhelming first but in the long run it will help you to understand the commands. I’d recommend starting with the progit book on Git’s web site. You don’t need to read the book from start to finish. Familiarize yourself with the basics and then jump to a relevant chapter.
2 Likes
@kmikkels I’ve installed the last version and tested it. ZEverything works good. One only thing which looks strange for me. When I choose full date format, then missing months and day are -01-01 or -12-31. I understand probably its easier for dates comparison. But its a bit incorrectly, because when we use year only, it means that we dont know month and day. But when you show -01-01 instead, we dont know is it really exact date with -01-01 or its script’s job. I agree the script should work as -01-01 but I think it should show anyway the date as it added in the config.
@Urchello I don’t agree.
If you only have years (or years-month) in from, I will assume the rest of the date to be as early as possible.
If you only have years (or years-month) in to, I will assume as late as possible.
If you will compare on years, I will strip everything except the year.
So to make it clear to the user, what I use for comparison, i need to show that in the date columns.
But, seriously, should you even download and “beta-test” before the developer give the go for a new version to beta-test?
It should be the developer, not the tester(s) that decide when a code has enough fixes to go to a new beta-test period.
Please let the man finish what he has started on and gives a “go” for a new test… else it will just be chaos…
Publishing to a GitHub repository may be different than you expect.
Updating the repository is a very deliberate operation and has an implicit request for public review. It may not be a Release Candidate or even fully functional. But it is a request for feedback. Developers work on their local machine and don’t update to the GitHub repository if there isn’t a ‘go’.
The Pull Requests to publish to the Addon Source as a Beta status is a request to a broader audience for feedback. And the “Stable” status Pull Request is for unrestricted release.
That may be true for the repositories in the Gramps project, but not for any repository…
I have been using multiple software published on git, where developers just say “wait for the release, this is not necessary up to date”.
And also say clearly that they will ASK if they need someone to test or control any code…
Of course, anyone can download, but do not expect that everything are updated UNTIL the developer actually say it is…
Seriously, you need to let the man be able to fix what he has been asked to fix!
1 Like
I see your point, but I just want to say, I have been very satisfied with the way the feedback to my work with the gramplet has been. I guess it depends on how the person works. The work with HistContext has been very dynamic, and I am grateful for all the help and feedback I have received,
It has definitely resulted in a better gramplet, I have learned a lot, and is confident in working with my ideas for more gramplets in the future.
2 Likes
Could the Feature Request be closed as complete?
0013498: [Historical Context] To be implemented in gramplet
version 0.2.26 covers all the mentioned items in the Feature Request.
(Note: I do not see a PR associated with committing to the Gramplet after 9 Nov 2024 )
1 Like
In the genealogical program webtrees the historical event files are all using the GEDCOM date syntax (see as an example german-wars-battles-worldwide).
For example “FROM 1 DEC 1900 TO 31 JAN 1901”. In GEDCOM dates, uncertain dates (JAN 1900), open ended date spans (FROM 2000) and the use of calendars (eg Julian dates) are all well defined. Why reinventing the wheel?
Not sure what you want with this post?
I don’t know webtrees, so I wouldn’t have a chance of knowing what they are using for comparing with history.
I missed the possibility to show what was going on in Denmark and Sweden, during my ancestors lifespan, so I made the gramplet. And someone suggested that I should use gramps date routines, which was a geat idea, and I implemented it.
So what do you want? That I should use webtrees? That I should figure out historical data from webtrees? I am confused.
Sorry for being confusing. Whenever I have to solve a problem I’m doing a research how this problem is solved elsewhere in order to learn. So I tried to understand how this problem was solved in Gramps.
My suggestion is to replace the two columns From and To in the historical event files in Gramps by one column using GEDCOM date spans. That would allow more flexibility and allows you to specify dates in the Julian calendar system or any other calendar, too. The handling of GEDCOM dates is a core function of all genealogical programs.
I don’t say that you should use webtrees instead of Gramps. But you can learn from other solutions. Maybe you can recycle the existing historical files for Danmark:
All webtrees code is open source.