Make a new release #77
Comments
|
I managed the previous releases. I too think that we should have another one very soon, however, I am currently very short on time. If someone would help out to tie loose threads together, make sure all bindings and ports are eoither deprecated or up to date .. this would be very helpful. The deployment/release process itself is pretty straightforward and automated then. I would definitely like to wait for sherief's |
|
Like for the last release I can help here a bit, if this is ok for all participants. Kimmi |
|
Finalizing the size_t branch should take me one to two weeks, then it'll need some attention from someone more familiar with the codebase (some internal functions like hashing are probably tied to 32-bit values and I'm completely unaware of how bindings to other languages work). We should be able to have a new release soon, and I will probably merge-in some enhancements I have to the Collada loader too. |
|
Any progress on this? |
|
Right now all data members use size_t (although some post-processing steps and format loaders have not been tested). The current ai* data structure should be ready for bindings generation. All that's left for this release is for someone to generate the bindings and, more importantly, check the internal functions I mentioned in my previous post. I'm not familiar enough with these parts of the code to do either, unfortunately. |
|
The main work will be to create the source-tar-ball and bindings. I can help here of course. Maybe in the next week we should be able to release a new version. Kimmi |
|
@sherief: I am currently on fire with lots of things to be finished up. In about 10 days I will have much more time, though, then I can look into the bindings. I've done so for previous releases, so it will likely be a smooth process. To throw in a release date, what about aiming for Mid October (i.e. a month from now)? |
|
@acgessler No worries, I thought that'd be the case so I didn't nag. The bindings are important, but I wouldn't want to ship something without the hashing functions looked at and various format importers are tested on the size_t branch. |
|
Created milestone for the release. Can we assign all relevant issues to it? |
|
Just tried it, should be possible. We all should have a look on the open issues. Same for the stuff on sourceforge. Kimmi |
|
@kimkulling Could you help migrate the relevant sf.net issues over to github? (i.e. just make new issues and link back to the old sf.net issue for the actual contents) |
|
Sure, I will take this task. |
|
Is there some message board like place where we can discuss that release? There are a few additions that I'd like to have in the next version and a triage process with someone more familiar with the codebase than me would be nice. |
|
We've once used www.zfx.info to discuss assimp releases, but unfortunately it is German language only - right now github seems to be the best place to discuss online, I'm afraid. However, you can find my skype name and contact info on my website, I'm quite often available to chat. |
|
We have the mailing list as a discussion board. And we should use it, It is public and it has a archive and it's english as well. Kimmi |
|
SO, I started to migrate the issues manually from sourceforge. Good news: some issues are already obsolete, bad news: I have to migrate a lot. Kimmi |
|
All issues are migrated. Kimmi |
|
Awesome, thanks for taking the time! So now let the cleaning begin ... ;-) |
|
Ok so I've been watching this for some time now and I'd like to say that it will probably take about another year for 4.0 to release. I think that's a dire outlook and you should only focus on API breaking changes for now for 4.0. Also, you should call it 4.0.0 from that release onwards so you can make little API changes with 4.1.0 but you can also make non-API-changing releases with 4.0.1 and also communicate to your users that it doesn't break. Please consider rescheduling some non-API bugs to post 4.0.0 and also consider adopting a different name scheme. The software will never be perfect but for now a new release would perhaps get some more developers interested and that might indeed help fix everything quicker. I'm actually asking you to rush this release a bit just to keep things rolling. Realise that those 25~ish issues you still want to do for 4.0rc is just too much and some are quite hard to track down. |
|
You're right. Maybe we should go over the existing defects/issues and see which ones are really showstoppers. Thanks a lot for your comments. Kimmi |
|
Agree. As a personal status update, I don't have much time for assimp right now, so I am barely catching up.Things will clear up in May from my side. |
|
Honestly guys, just tag a release an go from there. Software like assimp, a lot like wine or similar software, will simply never be "ready". There's always gonna be odd issues, quirks or just plain weird shit. Just tag a release and roll with it for now. You will attract some interest and maybe a bunch of pull requests to get you rolling quicker. Right now people go to your site and go "meh, no release for 2 years, probably dead". |
|
Hi, I just need the time to do the source release, that's all :-). And then we Kimmi On Thu, Apr 17, 2014 at 2:13 AM, Sven-Hendrik Haase <
|
|
Ji all, I just tagged 3.1 RC1 for testing. After testing this tagged version we Kimmi On Thu, Apr 17, 2014 at 10:13 AM, kim kulling kim.kulling@googlemail.comwrote:
|
|
Very nice. |
|
Please make package manager compatible tags in the future: 3.1rc1 would be perfect, for instance. |
|
So, I prepared the Release candidate 2, but I broke the material import of Kimmi On Fri, Apr 18, 2014 at 6:35 PM, Sven-Hendrik Haase <
|
|
It seems that the commit: broke the material import for obj. Kimmi On Mon, May 5, 2014 at 8:03 PM, kim kulling kim.kulling@googlemail.comwrote:
|
|
So, exept static library for IOS build all evil issues seems to be fixed. So I will take a look onto the static lib issue and then release 3.1. |
|
Hi all, I just marked the latest version on github's master as the 3.1 release. With best regards, On Mon, May 5, 2014 at 8:36 PM, kim kulling kim.kulling@googlemail.comwrote:
|
|
wow, great! i guess #184 could be closed as well... not sure if its worth to tag old versions/releases. |
|
It really isn't worth tagging old releases. Time only goes forward. Just close that issue. Please tag releases in the future though. |
|
3.1.1 is out and we will close this old issue. |
This project is becoming more and more important and interest is generally growing because it finally unfucks the whole 3D model situation a bit. As a result, I think releases should be made more often. The last release was over a year ago.
Many fixes have gone into assimp since then. Don't you think it's about time to make a new release and after that maybe make one every 2 months?
The text was updated successfully, but these errors were encountered: