Although I have a good understanding of NPM and bower to include packages in web projects, I would expect from meteor, which has a very own packaging logic, that core packages are kept up to date?
Meteor = make things easy, right? I struggled for a few hours, why meteor was not recognizing col-md-6 until I figured out it doesn't have version 3.
No it has version 3 , you can add that package using
meteor add mizzao:bootstrap-3
from meteor 0.9 version and above for more check here
(https://github.com/mangasocial/meteor-bootstrap-3)!
Meteor shipped with several packages as "core" when it was still pre-1.0. That was when no useful packaging system was available, so the folks behind Meteor were kind enough to get developers a quick start with providing several packages.
Now that we are post 1.0 they have decided to focus their energy on developing Meteor, and not bringing in packages that can easily maintained by the community. The packaging system is available and well documented so that MDG can refrain from shipping (and maintaining!) packages that are not essential for the Meteor platform.
While I personally would have liked to see each and every package I'd need in my projects to be part of the officially maintained core, it is simply not feasible. To avoid confusion, the bootstrap package is about to vanish from meteor core soon, as you can see from the History.md for the next version
Some packages are no longer released as part of the core release process: amplify, backbone, bootstrap, d3, jquery-history, and jquery-layout.
You've to have in consideration that Twitter (the company in charge of the project) isn't the official owner of the package in Atmosphere, It's a community package and if you don't like: you don't use it. That's pretty much how it works, I've had my dose of problems with atmosphere packages, now: I simply read most of the code before using a package. You can easily spot obvious mistakes/behaviours just by reading some lines.
Related
Preamble
My org is low-risk so we're planning to stick to LTS releases (.NET Core 3.1 at the time of this post.) The Nuget Package Manager Updates list, however, currently offers non-LTS updates (namely to .NET 5.0.)
Question
Is there a way to configure Visual Studio in a way to show LTS updates only? Alternatively, is there any other way I can achieve the same desired result?
(This question is actually almost a copy of Lion's original, but I'm hoping that improvements on api.nuget.org or in the way Visual Studio handles API results may result in a viable answer.)
Your question is a real good question. And many community members want this feature on PackageReference for net core projects.
In fact, what you want is not supported on PackageReference so far. And net framework projects with packages.config nuget management format can realize it. See this official document.
Under packages.config, you can use allowedVersions node for nuget packages on packages.config file, such as [3.1.0, 5.0.0). It means 3.1.0 <= current version < 5.0.0. You can only update the nuget package under that range on the Nuget Package Manager UI.
It is quite useful feature but Microsoft has not added this feature for the new-sdk project with PackageReferece. Therefore, many community members has raised this issue on github which is still in processing.
And the Team has planned to fix the problem on December 20. So I suggest you could follow that github link and add any comments to describe your issue to raise more attention from Microsoft' team. All of them will help solve the problem as soon as possible.
We have 2 solutions.
SolutionA is an internal solution where we put reusable code through our products
For the sake of the question, it has only two projects NugetProjectA and NugetProjectB which has a project reference to NugetProjectA.
SolutionB its a solution that has package references towards SolutionA via nuget.
The thing that troubles is:
add new method added in NugetProjectA
add new method in NugetProjectB project that uses previous method
publish new version of NugetProjectB
update nuget reference on Project of SolutionA
execute in Project newly added method of NugetProjectB
Since we didn't publish the NugetProjectA updated version, last step described will fail.
This seems to be a easy problem to solution. But imagine this with many more projects in SolutionB and many more in SolutionA.
Your question is vague and open-ended, so there isn't a simple, concise answer. Honestly it could easily be a multi-post blog series or even a short book. I'll try to give some general suggestions, but I'm not going to go into a lot of details to avoid making this answer too long.
Mono-repo vs multiple repos
Just like the microservice craze from a few years ago, you should first ask yourself if you need it. Having all your source code in a single repository and solution might make it feel "legacy", and it sure seems nicer to have a 3 minute build of a component rather than a 30 minute build of a whole system when checking in a 1-line bug fix. But are the problems you listed in your question worth the benefit of a shorter CI build?
On the other extreme, Google may famously run almost everything out of a single repository, but they have teams of people doing nothing more than managing their mono-repo and build system because a large number of developers working on a single repo have a different set of problems. These are engineers not working on customer applications. If their work make other teams more productive, then it can be worthwhile.
You need to figure out what's best for you, but given the problem you described in the question, maybe you have too many repos/solutions and your processes could be faster with fewer mistakes if you consolidate a little.
Automation
The next best thing is to just use good engineering practises. Automate as much as possible to reduce the risk of human mistakes, including automating processes that validate that manual processes are followed correctly.
Have the a CI or CD pipeline push packages, so you can't forgot to push dependencies, like in your example.
There are tools that will automatically generate a version number from the git history based on the number of commits since the versioning config file was checked in. This prevents you from forgetting to increment the package version when you check in a change to the package.
Have tests to make sure the package works before pushing it. You could make it as simple as making sure that dependencies exist, but you could also go further and have test programs run that use the package to ensure that backwards compatibility isn't broken and that new features actually work as expected. Have these tests run before pushing the package, so if the tests fail, you don't push a bad package.
You can have a pipeline that will automatically create pull requests on solutions that use a package when a new version of one of your packages is published. You can even automatically merge it, but you'll want to make sure you have real good tests to avoid a buggy package cascading into a huge mess, particularly if you do automatic deployments on successful builds.
Be creative and think about other ways you can automate your processes to make things easier for yourself and your team.
But be pragmatic about what you automate. There's no point spending a week full time to automate something that only takes you 5 minutes once a month to do manually. But if the manual process sometimes goes wrong and causes hours or days of effort to fix, then that makes automating the process more worthwhile.
Use modern features
The .NET ecosystem has changed a lot in the last 2-3 years since .NET Core was announced. Now packing with MSBuild (either dotnet pack or msbuild -t:pack) is easier to create packages than creating .nuspec files and making sure you do the right things to get project dependencies packed as nuget dependencies, getting all files in the right places, etc. If your class library uses SDK style projects, then there's nothing extra to do. If your project is a traditional project, you'll need to use PackageReference for your NuGet dependencies (or specify <ProjectStyle>PackageReference</ProjectStyle> as an MSBuild property in your project file), and then reference the NuGet.Build.Tasks.Pack package.
Version the application, not each package
Like the mono-repo vs multiple repos point, considering versioning all packages in the application with a single version number, rather than versioning each package individually. Yes, this means you'll sometimes (or maybe often) publish a new version of a package that doesn't have any code changes to the previous version, but it simplifies the release considerably. Coupled with packing with MSBuild in the section above, you can create a Directory.Build.props file in your repository root, and set the <Version> property to your app version, and all projects in the repo will have the same version. So, when you're ready to release, bump the version in a single file and every project and every NuGet packages will have the same version.
Summary
In an ideal world each component would be reusable in different applications, in a separate source code repository, each package individually versioned using semantic versioning. But in the real world this adds a lot of development time complexity. Your customers may be happier to get bug fixes and new features more quickly, even if the version number of packages are less meaningful. So, make data driven decisions. If you're frequently having dependency version problems, reduce your dependencies so there are fewer things that can go wrong.
Don't get me wrong, there are many good reasons to have multiple projects, multiple solutions, multiple repositories. Just make sure that the reason you're doing them is because it helps your team/company be more productive, not for idealistic reasons that are slowing you down or causing bugs.
We've recently had several hacks on our one server. We've been advised to upgrade all scripts. The problem is, the Drupal installations. Upgrading these are a massive task. I would like to know, out of fellow Drupal users, in your experience, how unsafe is it to remain on a say version 6.10 as apposed to upgrading 6.28 (the latest)? Is there a point at which you can say: this is really too old now and an upgrade is absolutely necessary?
I'm not too worried about the modules, my concern is the Core Drupal installation. Does it ever become a security risk, or can you stay on the older versions?
"Upgrading these are a massive task"
Not necessarily! I find using git a pretty safe way to deal with such upgrades.
My basic workflow is usually to:
- create a repository with the current Drupal version.
- download the latest core version
- rsync the current version with the latest core version
- update the repository
As expected, I do all of the above on my local version, after checking that everything is working fine. I update the remote repository, then update the actual live site from git.
If you're not familiar with git, basic tutorials are easy to find online. The idea here is not to explain the process in details, rather to send you in the right direction. You will find that it's a pretty flexible workflow, a great way to update modules and generally any type of code.
I've downloaded package TideSDK-1.2.1.RC1-0be9cd89-windows-7-x86-64.zip from tidesdk.org. Installer was found in tidesdk\sdk\win32\1.2.0.RC4\installer. This installer doesn't work: "Installation failed. The installer could not determine the application path."
What's wrong with it? Is it the only (right) way to install TideSDK? No docs on topic were found in resources and links on tidesdk.org.
It looks like you picked up an artefact from our Continuous Integration System from some point in time in development. We will eventually expose a Nightly Build site for developmental releases. That said, we will do this once the 1.3.0-beta is ready so we can properly support you with developmental artefacts.
Please use the legacy 1.2.0.RC4 in the interim that can be downloaded from front page of tidesdk.org until TideSDK 1.3.0-beta is available (which will be along very soon). This will serve your development needs in short term as we continue the work to get the beta prepared.
A new 'Getting Started Guide' will be up later today for the legacy 1.2.0.RC4 as there have been many requests for this help.
We appreciate how much attention our project is getting and have been working hard as a team to produce great documentation. Despite this, our efforts were primarily targeted on the API documentation at the outset. We experienced a surge of interest prior to getting the new guides in place. Our apologies to anyone new that has experienced any difficulty getting started. We appreciate your patience while we fill these gaps.
The new documentation is being prepared in anticipation of the 1.3.0 release so that we have great API docs, guides, and example apps when the time arrives. It is targeted for the end of September. We hope to also have our Tide Builder app available at that time to provide a nice app to help create, run and package your apps. There will also be an enhanced tidebuilder CLI since a tool with a UI will be strictly an option. For those that appreciate minimalism, this will get you going with no more than the SDK and a text editor.
You need to download Titanium Studio first.
Once that's done, you can install the package : Help menu > Install Sepcific Titanium SDK.
I'm trying to find 1, just 1, working sample project for Red5 that's updated to work against the latest 0.9 release without missing jars and other nonsense.
Right now, it's at v0.9 and the libs are different from other versions. They have 5 pathetic examples on their website, but all were built with the older versions. For these 5 old examples, I could use the Add External JARS feature to try and add libs from previous versions, they don't mention which versions they were built against and I'm not going to try each previous version to see which works (I already did and nothing works). They don't seem to be putting any effort into updating or marketing their open source project.
Anyone who's more intelligent and can shed some light on behalf of these fools?
What sorts of issues are you having? What sorts of projects are you trying to build?
I'm by no means an expert on this - and I admit that the lack of documentation is pretty frustrating.
However, I just downloaded their latest, installed it and got the olfa demo running pretty seamlessly.
The source for the demos are available here, and I use these to work out what I need.
http://www.smartfoxserver.com/ makes use of red5 in someway. Perhaps you can find something useful in their (well documented) examples, good luck.