Maybe I was lucky because I always used MSVC, and used Qt just for the library, not for the IDE. Maybe I don’t remember well from years ago, but I followed 4. Publishing a Release · fritzing/fritzing-app Wiki · GitHub which is somewhat good documentation, there are points not completely updated, but for a medium-skilled developer, they are still quite understandable. No problem with this, in my opinion.
Please forgive me if I’m wrong for what I’m about to write.
What leaves me very puzzled of all this thread is that it seems to me that Fritzing is licensed as free software, but at the same time, the most important developers of Fritzing do not like it to be free software, and hinder it being freely downloaded, studied, recompiled, modified etc. This leaves me really stunned.
You wite “Having version number ‘release’ tags in the repository is a convenience, not a necessity for free/gpl etc software.”. I think that no, this is not true (pls forgive me) because GPL does not distinguish the source between .C/.CPP files and resouces files. Or the source is the original source, or it is not. With all the code, release, comments, etc. But apart of this, why should someone change the release tag, without saying that clearly? The only possible explanation seems to make it obscure to use the source. And this clearly clashes with the essence of free software, at least this seem to me. You make a free software if you want the whole world to “own” it, or not? If this was not your objective, you wouldn’t have marked it as free software in the same place, don’t you? So, why mess with the release tags?
Please understand that I don’t want to “steal” Fritzing. I don’t care about having the source, having only to grep -rsl ‘0.9.6’ in it, adapt two files and then obtaining the current version. For what I’m using it, the 2015 version is more than enough. I just like free software, and I always thought Fritzing was a software worth using it, just because it was real free software.
I believe this issue on github indicates that @microMerlin is correct and the github source is up to date with at least 0.97 and I expect also 0.98 (although I closed the issue on the generic IC when 0.9.8 was released before the commit that fixed it was added to the issue) so all that is “missing” is a release tag not the source code as far as I can see.
You will need clarify what you mean by ‘original’ here. GitHub - fritzing/fritzing-app: Fritzing desktop application is the original, base application source code repository. With history of all changes that made through a commit, pull, merge cycle. pick a branch and date, then pull that version from the repo.
The only “problem” here, is that no git tag was added to the repository when a new binary version was uploaded. The uploads got a new version number so that people could tell what was older or newer. Since the version information is in the ‘about’ information, you should be able to narrow it down by grepping for the version string in the source, then doing a ‘blame’ to see when it changed. That won’t be 100%, because commits and development builds happen without changing the version strings. I don’t know if the version got changed when commits planned for the release started getting added, or just before the build for the release. You can narrow that further by limiting to commits before the datestamp on the binary.
Personally, I’d “like” to see the commit guid as part of the version details. To be able to reproduce a specific build when testing bug fixes. Because unversion, unreleased binaries still need debugging, and might be a candidate for (temporary) new source branch. Whether that ever gets merged (or even pushed) back into the main branch or not. No separate release tag needed. A “convenience” to make it easier to track the amount of change between major releases. The tags do not change the source code, or what is original. They are just an alias for a commit guid.
The “correct” processes to use with the tools is open to debate. Whole flame wars. Obviously the process currently being used for fritzing_app falls outside of what you consider acceptable. So suggest a concrete improvement somewhere appropriate. Perhaps the issues section of the fritzing_app repo. Something like:
“When a binary is built for uploading, add the matching version tag to the commit in the repository, before the binary is uploaded for public access”
This particular forum is for users of the application, to share how to do things, including working around bugs. People here are only incidentally involved with the source code, and even less with managing the repository or official releases and uploads.
@vanepp : again, I’m not questioning if the github repo is behind of a version tag, or one bug, or 100 bugs, or which particular IC bug. I was just trying to understand why it is behind at all. If it is simply an oversight, or something else. Just because it would be so simple, and so useful, to update the Github repo and keep it up-to-date, and use it as the reference source code. The situation is clear for me now, time will tell. Best regards, Luigi
@microMerlin : let me answer to the last parte, because it is the essential part. Please understand that I wrote here not to pollute the forum, but only because it seems to be the place where we talk about Fritzing. If talking about a particular IC is good, and taliking about the whole Fritzing project is not good, then OK. But I think the point was clear weeks ago. No speculation, time will tell.
@vanepp can you please point me to the source code for 0.9.8 on github? To me the develop branch looks most recent. Since 0.9.6b (Ensure fzz lock directory exists) there have been five commits. Only two of them are functional changes, only one is a bug fix (fixing #3340 and #2308). This does not match the list of changes in 0.9.8 at all which claims to fix 250 issues since 0.9.6.
This is not an issue of missing release tags. The code just is not available.
No I can’t as I am a user like most other folks here. I don’t have commit access to the repository and an not all that familiar with github. Your best bet would be to open an issue on github where the folks that have commit access to the repository are. I am assuming (and assuming is all that I am doing!) that the repository is up to date. Many issues being fixed are old (because development had entirely died with no releases at all for around 5 years!) so the commits may be across the last few months (likely to the development branch rather than master I expect.) I would expect the master branch to be 0.9.8 but I don’t know for sure.
Hi AlanChen. Obviously I never said that Fritzing is not a good piece of software and would not be worth a payment.
But the point here is another one: Fritzing is free software. Indeed, being a free software involves much more deep aspects other than being paid or not paid.
Moreover, who originally started the Fritzing project years ago, marked it as free software. And put a sentence in the license to protect it forever in respect of being free, to guardantee anyone who wants it that Fritzing continues to be free software, independently from it being good or bad, up-to-date or obsolete. These are facts much more relevant than having to pay some dollars to download a binary. Let’s see.
that’s my thought.